Создание службы Linux systemd

Обновлено: 21.11.2024

Каждая операционная система использует фоновые процессы для поддержки различных операций системы. В системах на базе Linux эти процессы известны как демоны, и они запускаются и обслуживаются демоном инициализации, который запускается сразу после загрузки системы. Во многих наиболее популярных дистрибутивах Linux этим демоном инициализации является Systemd, поэтому понимание того, как он работает, необходимо для эффективного администрирования сервера Linux.

В этом руководстве вы изучите основы Systemd и команду systemctl, которая используется для управления службами Systemd. В частности, вы узнаете, как просматривать и редактировать файлы конфигурации Systemd, а также как останавливать, запускать, включать или отключать службы Systemd с помощью systemctl .

Предпосылки

Чтобы выполнить это руководство, вам потребуется:

  • Один сервер Ubuntu 20.04 с пользователем без полномочий root с доступом sudo.

Шаг 1 — Просмотр файлов модулей Systemd

Самой важной абстракцией Systemd является модуль, представляющий любой ресурс, поддерживаемый операционными системами, такими как демоны, сокеты, устройства и многие другие. В этом разделе мы настроим таргетинг только на службу.

Каждый конкретный модуль Systemd имеет свою конфигурацию и, как правило, несколько конфигураций с различными приоритетами и областью действия. Эти конфигурации сохраняются в специальных файлах, называемых юнит-файлами. Как правило, файлы модулей находятся в следующих трех каталогах (перечисленных в порядке возрастания приоритета):

  1. /lib/systemd/system : самые общие юнит-файлы с самым низким приоритетом. Вы не должны изменять файлы в этом каталоге.
  2. /run/systemd/system : конфигурация модуля среды выполнения. Эти файлы изменяют поведение модуля во время выполнения. Они создаются динамически и существуют только для текущего сеанса загрузки.
  3. /etc/systemd/system : юнит-файлы с наивысшим приоритетом. Если вам нужно изменить конфигурацию устройства, вы обычно редактируете файлы в этом каталоге.

Конфигурация для конкретного объекта

В тех случаях, когда вам нужно отредактировать только определенные параметры в файле модуля, вы обычно создаете подкаталог, имя которого является сервисом модуля с суффиксом .d (например, подкаталог example.d принадлежит объекту примера). Этот подкаталог будет содержать один или несколько файлов с суффиксом .conf, которые изменяют и расширяют конфигурацию базового устройства.

Вы можете выполнить команду ls, чтобы получить список всех устройств в каталоге /etc, которые используют конфигурацию для конкретного устройства:

Опция -d ограничивает вывод только каталогами, а /etc/*.d указывает, что должны быть представлены только каталоги в /etc, которые заканчиваются суффиксом .d.

Вышеприведенный вывод показывает все каталоги конфигурации объектов для каждой службы. Например, обратите внимание на каталог /logrotate.d для службы logrotate. Здесь вы можете отредактировать или создать новую настройку ротации журналов (дополнительную информацию см. в разделе Как управлять журналами с помощью Logrotate в Ubuntu 20.04).

Структура юнит-файлов Systemd

Структура единичного файла точно определена. Каждый из них разделен на разделы, и каждый раздел состоит из директив.

Давайте просмотрим содержимое файла модуля для службы rsyslog в /etc/systemd/system, выполнив команду cat:

Вы увидите содержимое файла на экране:

В выходных данных показаны определения различных разделов и их директивы для службы rsyslog. Каждая директива начинается с новой строки с ключевого слова, за которым следует значение (например, Description=System Logging Service). В приведенном выше файле есть три раздела:

  • [Единица]: определяет метаданные единицы и ее связь с другими единицами.
  • [Сервис]: используется для настройки сервисного модуля. Наиболее распространенной директивой в этом разделе является Type, которая сообщает Systemd, как управлять службой и узнавать ее состояние. Type=notify указывает, что служба уведомит systemd после завершения запуска. Директива ExecStart определяет полную команду, которая должна быть выполнена для запуска службы.
  • [Установить]: определяет поведение устройства после его включения. Директива WantedBy указывает связь между модулем и другими, а Alias ​​определяет альтернативные имена модуля (в нашем случае rsyslog и syslog — это одни и те же модули Systemd).

Для получения дополнительной информации обо всех других разделах модуля и их директивах см. документацию Systemd.

Шаг 2 — Проверка состояния службы с помощью systemctl

Команда systemctl — это утилита, которая управляет Systemd и его модулями. Этот инструмент позволяет нам проверять состояние устройства и отключать или включать его по мере необходимости. Идите вперед и просмотрите список всех доступных юнитов в вашей системе с помощью команды ниже:

Опция --type=service показывает только единицы типа service , а --no-pager предотвращает передачу вывода на пейджер less. Вывод команды должен появиться на экране:

Вы также можете просмотреть подробную информацию о конкретном блоке. Идем дальше и проверяем состояние службы rsyslog, выполнив systemctl с подкомандой status:

Вы увидите вывод программы на экране:

Вышеприведенный вывод подробно описывает службу rsyslog. Вы можете видеть, что служба включена и работает уже почти три недели. Несколько самых последних записей из журнала отображаются в конце вывода.

Если вас не интересуют такие подробные выходные данные, вы можете использовать команду systemctl с подкомандой is-active или is-enabled.

Это показывает простой логический статус, указывающий, что служба rsyslog активна:

Выполнить systemctl с подкомандой is-enabled для rsyslog:

Снова отображается простой вывод статуса:

Шаг 3. Запуск и остановка служб с помощью Systemctl

В этом разделе вы измените статус службы с помощью systemctl. В следующих примерах мы будем использовать systemctl с sudo, потому что для изменения файлов модулей Systemd требуются привилегии root. Подкоманда start используется для запуска службы модуля Systemd, а подкоманда stop выполняет противоположную операцию. Обе операции не сохраняются после перезагрузки.

В вашем дистрибутиве Ubuntu уже активирована служба rsyslog. Остановим его, выполнив команду systemctl stop:

Энтони Хеддингс

Энтони Хеддингс
Писатель

Энтони Хеддингс (Anthony Heddings) – штатный облачный инженер LifeSavvy Media, технический писатель, программист и эксперт по платформе Amazon AWS. Он написал сотни статей для How-To Geek и CloudSavvy IT, которые были прочитаны миллионы раз. Подробнее.

Серверы Linux предназначены для постоянной работы; вместо того, чтобы запускать важные программы вручную и оставлять их в сеансе tmux, вы должны добавить их в systemd как службу, которая будет автоматически запускаться при загрузке и перезапускаться в случае возникновения ошибок.

Работа с Systemd и службами

Systemd хранит конфигурацию служб в двух местах. Первый — это /lib/systemd/system/, где вы найдете конфигурацию для многих служб в вашей системе. Здесь устанавливаются службы установки большинства программ. Второй — /etc/systemd/system/, который переопределяет каталог /lib/systemd и обычно используется для размещения пользовательских сервисов. Также есть /etc/systemd/users/, который запускает сервисы для отдельных вошедших в систему пользователей. , например получение почты.

Многие из этих служб не работают постоянно, как nginx или MySQL. Вы можете распечатать список используемых в данный момент служб с помощью:

Службы со знаком «+» запущены, а службы со знаком «-» в настоящее время остановлены. Вы можете просмотреть более подробную информацию с помощью:

Поскольку службы работают в фоновом режиме, они не регистрируют свои выходные данные на вашей консоли, а регистрируют выходные данные в журнале systemd. Команда «status» покажет последние несколько строк этого журнала, но вы можете прочитать их напрямую с помощью:

Эта команда выводит 50 последних записей журнала ( -n ) из службы nginx ( -u ). Он настроен так, чтобы печатать все и начинать снизу, следуя за новыми записями журнала по мере их создания ( -f ).

Конечно, многие приложения по-прежнему будут записывать большую часть информации в свои журналы доступа или журналы ошибок, поэтому обязательно проверяйте и их. Журнал отслеживает события, зарегистрированные непосредственно в консоли, что может быть полезно для отладки ваших собственных служб.

Простая настройка службы

Systemd используется в Linux для многих целей; каждый объект, которым он управляет, называется единицей и имеет соответствующий «файл единицы», определяющий, что они из себя представляют. Это могут быть простые сервисы, такие как nginx или MySQL, но они также могут быть такими вещами, как точки монтирования, устройства, сокеты и множество других скрытых вещей, которыми управляет systemd. Объекты также могут быть целями, используемыми для управления запуском других служб (например, после инициализации сети).

Однако в этом случае вы, вероятно, просто захотите настроить приложение как базовую службу. Для этого вам нужно будет создать новый юнит-файл, который вы захотите поместить в /etc/systemd/system/ и назвать с расширением .service:

Файлы модулей имеют несколько разных разделов, но в целом они будут выглядеть примерно так:

Начнем с раздела [Блок], который определяет набор метаданных об объекте. Директиву After= можно использовать для задержки активации модуля до тех пор, пока не будет запущен другой модуль, например сеть, или другая служба, например mysql.service. Это не делает ее жестко зависимой от этой службы, хотя вы можете сделать это с помощью Requires. = или Хочет= директивы. В этом разделе также настраивается максимальное количество попыток запуска модуля, прежде чем systemd полностью сдастся; поскольку вы, вероятно, хотите, чтобы он продолжал попытки, вы можете установить это значение на 0, чтобы отключить это поведение.

Далее идет раздел [Сервис], относящийся к файлам сервисных модулей. Здесь вы настроите параметры Exec. Пользователь будет запускать службу как определенный пользователь. Вы можете установить это на свою личную учетную запись пользователя, корневую или пользовательскую учетную запись службы. Просто убедитесь, что у пользователя достаточно прав для выполнения своей работы.

Здесь есть несколько различных директив для указания запускаемых программ. ExecStartPre запустится первым, что позволит вам выполнить все необходимые настройки до того, как служба действительно запустится. ExecStart — основной исполняемый файл. ExecStartPost запускается позже, а ExecStop запускается при завершении работы службы. ExecReload — это специальная директива, которая используется, когда вы вызываете «перезагрузку» вместо перезапуска. Это позволяет выполнять перезагрузку конфигурации во время выполнения, если ваше приложение поддерживает такую ​​возможность.

Наконец, раздел [Install], который определяет некоторые дополнительные действия, связанные с тем, как systemd обрабатывает модуль. Это чаще всего используется для указания директивы WantedBy=, которая используется, чтобы сообщить systemd, когда запускать вашу службу, и создает символические ссылки между целями и их зависимыми модулями. Если вы не знаете, какую цель использовать, multi-user.target будет запускать службы при запуске после того, как почти все загружено.

В целом настройка довольно проста, и все, что вам действительно нужно сделать, это указать свой исполняемый файл в качестве аргумента в разделе [Service]. После того, как ваша служба будет создана, вам нужно будет перезагрузить демон systemctl, чтобы он обновился с вашими изменениями:

И включите его (который будет запускать его при загрузке в соответствии с конфигурацией устройства):

Затем запустите службу:

Теперь служба должна работать в фоновом режиме, и вы можете проверить logctl, чтобы просмотреть его вывод. Если он завершится, systemd автоматически запустит его снова, и он должен работать при загрузке вместе с другими службами в вашей системе.

Если вам нужно перезапустить службу, вы можете использовать:

Что выполнит директиву ExecStop=, остановит устройство, а затем снова запустит его.

  • › Как запускать сборки Github Actions на собственных серверах с помощью собственных исполнителей
  • › Как проверить, запущен ли демон Docker или контейнер
  • › Как развернуть веб-сервер Caddy с помощью Docker
  • › Что нового в TypeScript 4.6?
  • › Как добавлять, заменять и удалять теги изображений Docker
  • › CloudFoundry или Kubernetes: какую облачную платформу выбрать?
  • › Как использовать Docker для упаковки приложений CLI

Вышеупомянутая статья может содержать партнерские ссылки, которые помогают поддерживать CloudSavvy IT.

Служба – это программа, которая запускается автоматически при запуске компьютера и ожидает выполнения своей работы в фоновом режиме. Служба обычно не имеет графического пользовательского интерфейса и работает без взаимодействия с пользователем. Наиболее известными службами являются определенные веб-серверы, почтовые серверы или серверы баз данных, например, apache, MySQL и многие другие. Но также обнаружение оборудования или автоматическая интеграция (монтирование) USB-накопителей, например, выполняется службами.

В принципе существует два типа служб: внутренние для задач, которые актуальны или связаны с аппаратным обеспечением при запуске системы, и другие службы, которые впоследствии устанавливаются пользователем и обычно включают в себя все серверные службы. В технических терминах или на компьютерном жаргоне сервисы также традиционно называют демонами. Поэтому буква «d» часто используется в качестве последней буквы в программе для обозначения некоторых служб, например, когда серверный компонент sshd для SSH или mysqld для MySQL.

Принимая во внимание, что Systemd — это системный и сеансовый менеджер (система инициализации), который отвечает за управление всеми запущенными в системе службами в течение всего времени работы компьютера, от процесса запуска до завершения работы. Процессы всегда запускаются параллельно (насколько это возможно), чтобы процесс загрузки был как можно короче. Теперь, когда мы создаем файл конфигурации, который заканчивается на .service и содержит код процесса, контролируемого и контролируемого Systemd; известен как файл Systemd Service Unit. Единицы создаются, например, для служб, таймеров, точек монтирования, сокетов, пространства подкачки и устройств.

Следовательно, systemd получает все свои значения по умолчанию и настройки для администрирования из файлов, в терминологии systemd это «юниты». Различают единицы, которые применяются во всей системе, и те, которые применяются только к соответствующей пользовательской области.

Существуют различные типы единиц, например единицы обслуживания для запуска служб или единицы таймера для (повторяющегося) выполнения действия в определенный момент времени. Все типы юнит-файлов объединяет то, что они имеют структуру, аналогичную ini-файлам. Они состоят из нескольких разделов (в большинстве случаев из трех), называемых в systemd «разделами», в которых хранится ряд пар ключ-значение, называемых в systemd «директивами».

Командная строка

Инструмент для управления systemd из командной строки или в терминале называется systemctl . Большинство команд глубоко вмешиваются в систему и поэтому требуют прав root, поэтому эту команду необходимо запускать с правами sudo для выполнения необходимых операций.

systemd записывает информацию журнала в центральный журнал. Это можно прочитать с помощью journalctl , включая параметры поиска и фильтрации.

общесистемные единицы

usr/lib/systemd/system: здесь находятся все файлы юнитов, которые были предварительно установлены службами для всей системы. /etc/systemd/system: здесь находятся все файлы общесистемных юнитов, которые создаются или редактируются пользователями. Для этого необходимы рут-права. Если в /etc/systemd/system есть юнит-файлы с тем же именем, что и в usr/lib/systemd/system, предпочтение отдается файлам из /etc systemd/system, т.е. они загружаются системой.

Типы единиц

Существуют разные типы единиц измерения, которые systemd обрабатывает по-разному в зависимости от расширения имени файла:

Здесь мы говорим о модуле .Service

Создайте свой собственный простой модуль или файл службы systemd

Замените-file-name на имя, которое вы хотите дать. Вставьте приведенный ниже блок текста:

Измените элементы, выделенные жирным шрифтом, в приведенном выше блоке кода и сохраните файл. Нажмите Ctrl+X, введите Y и нажмите клавишу Enter. Например: если мы хотим создать служебный файл для инструмента мониторинга Glances Linux, чтобы он работал в фоновом режиме, описанные выше шаги будут такими:

Вставьте приведенный ниже блок текста:

Сохраните файл. Нажмите Ctrl+X, введите Y и нажмите клавишу Enter.

Пояснение:

[Установить]:

В разделе "[Установить]" ключ WantedBy указывает, когда устройство будет запущено. Возможны разные значения:

Цель описание
multi-user.target для многопользовательских систем с графическим входом в систему или без него (соответствует уровню выполнения 3)
graphical.target для многопользовательских систем, которые должны иметь графический интерфейс входа в систему (соответствует уровню запуска 3 плюс графический вход в систему)
rescue.target Однопользовательский режим обычно требуется только для восстановления системы (соответствует уровню выполнения 1)
reboot.target Модуль выполняется только при перезапуске системы
poweroff .target Устройство запускается только тогда, когда система начинает выключаться
default.target Этот default.target не является «настоящая» цель, а символическая ссылка на другую, реально существующую цель. В стандартной установке рабочего стола Ubuntu этот default.target — graphical.target .

Активировать создание системных сервисных единиц вручную

systemd — это системный и сервисный менеджер для операционных систем Linux. Когда вы устанавливаете любое приложение из репозитория, оно помещает файл сервисного модуля в каталог systemd, и вам не следует изменять эти файлы напрямую.

Файлы модулей systemd находятся в следующих трех каталогах:

  • /usr/lib/systemd/system/ — файлы модулей systemd удалены после установки пакета.
  • /run/systemd/system/ — файлы модулей systemd, созданные во время выполнения.
  • /etc/systemd/system/ — юнит-файлы systemd, созданные командой systemctl enable, а также юнит-файлы, добавленные для расширения службы.

Иногда вам может понадобиться создать файл сервисного модуля для пользовательского приложения, демона или скрипта. Можно добавить много параметров, но мы добавим лишь несколько значений, чтобы упростить файл модуля для лучшего понимания:

Чтобы узнать больше о systemd и systemctl, обратитесь к следующим статьям:

Например: чтобы запустить собственный сценарий при загрузке в системе systemd, вам необходимо создать файл пользовательского модуля службы. Следующая процедура описывает общий процесс создания индивидуальной единицы обслуживания:

Создание пользовательского скрипта

Следующий сценарий оболочки запишет приветственное сообщение в файл следующим образом:

Создание файла модуля systemd

Вам потребуется создать файл пользовательского модуля службы в каталоге ‘/etc/systemd/system/’, поскольку он зарезервирован для пользовательских сценариев. Любой юнит-файл в «/etc/systemd/system» переопределит соответствующий файл в «/lib/systemd/system».

Синтаксис: файл модуля systemd состоит из трех разделов:

Чтобы продемонстрировать это, мы создадим файл сервисной единицы systemd с именем custom.service.

Раздел-1:

  • Подразделение . В этом разделе представлена ​​основная информация об услуге.
  • Описание : краткое описание сервисной единицы. Описание появляется рядом с названием службы, когда вы выполняете команду systemctl status UNIT.service.
  • После: определяет порядок запуска модулей. Блок custom.service будет запущен только после запуска блока network.target.

Раздел-2:

  • Служба . В разделе "Служба" приведены инструкции по управлению службой.
  • Тип: определяет тип службы systemd. Он идентичен «Type=simple», но в то же время демон должен отправить сигнал systemd, когда он будет готов.
  • ExecStart: используется для запуска службы, включая полный путь к фактическому исполняемому файлу службы.

Раздел 3:

  • Установка. В разделе «Установка» приведены инструкции по установке службы systemd.
  • WantedBy : параметр «WantedBy» указывает, для какой цели следует запускать данную единицу службы. В этом примере custom.service использует multi-user.target, поэтому systemd запускает custom.service при загрузке multi-user.target при запуске.

Установите для исполняемого файла разрешение custom.service

Чтобы добавить новую службу в systemd, запустите:

Чтобы запустить custom.service, выполните:

Чтобы включить custom.service при загрузке, выполните:

Наконец перезагрузите систему, чтобы проверить, выполнил ли custom.service сценарий при загрузке, как ожидалось, проверив выходной файл.

Да, это сработало.

Приветствую вас

В этом руководстве мы объяснили, как создать пользовательский файл сервисной единицы systemd в Linux.

systemd — это система инициализации и системный менеджер, ставший новым стандартом для дистрибутивов Linux. Из-за его широкого распространения знакомство с systemd того стоит, так как это значительно облегчит администрирование серверов. Изучение и использование инструментов и демонов, входящих в состав systemd, поможет вам лучше оценить мощность, гибкость и возможности, которые он предоставляет, или, по крайней мере, поможет вам выполнять свою работу с меньшими трудностями.

В этом руководстве мы обсудим команду systemctl, которая является центральным инструментом управления системой инициализации. Мы расскажем, как управлять службами, проверять статусы, изменять состояния системы и работать с файлами конфигурации.

Обратите внимание, что несмотря на то, что systemd стала системой инициализации по умолчанию для многих дистрибутивов Linux, она не реализована повсеместно во всех дистрибутивах. Если во время выполнения этого руководства ваш терминал выводит ошибку bash: systemctl не установлена, вероятно, на вашем компьютере установлена ​​другая система инициализации.

Управление услугами

Основная цель системы инициализации — инициализировать компоненты, которые должны быть запущены после загрузки ядра Linux (традиционно называемые компонентами пользовательской среды). Система инициализации также используется для управления службами и демонами сервера в любой момент работы системы. Имея это в виду, мы начнем с некоторых основных операций по управлению услугами.

В systemd целью большинства действий являются «юниты», то есть ресурсы, которыми systemd умеет управлять. Модули классифицируются по типу ресурсов, которые они представляют, и определяются с помощью файлов, известных как файлы модулей. Тип каждого блока можно определить по суффиксу в конце файла.

Для задач управления службами целевой единицей будут единицы службы, файлы которых имеют суффикс .service . Однако для большинства команд управления службами вы можете вообще не использовать суффикс .service, поскольку systemd достаточно умен, чтобы знать, что вы, вероятно, захотите работать со службой при использовании команд управления службами.

Запуск и остановка служб

Чтобы запустить службу systemd, выполняя инструкции в файле модуля службы, используйте команду start. Если вы работаете как пользователь без полномочий root, вам придется использовать sudo, так как это повлияет на состояние операционной системы:

Как мы упоминали выше, systemd знает, что нужно искать файлы *.service для команд управления службами, поэтому команда может быть набрана следующим образом:

Хотя вы можете использовать приведенный выше формат для общего администрирования, для ясности мы будем использовать суффикс .service для остальных команд, чтобы четко указать цель, с которой мы работаем.

Чтобы остановить текущую службу, вы можете использовать команду остановки:

Перезапуск и перезагрузка

Чтобы перезапустить запущенную службу, вы можете использовать команду перезапуска:

Если рассматриваемое приложение может перезагрузить свои файлы конфигурации (без перезапуска), вы можете ввести команду reload, чтобы инициировать этот процесс:

Если вы не уверены, есть ли у службы функция перезагрузки своей конфигурации, вы можете выполнить команду перезагрузить или перезапустить. Это перезагрузит конфигурацию на месте, если она доступна. В противном случае он перезапустит службу, чтобы новая конфигурация была принята:

Включение и отключение служб

Приведенные выше команды полезны для запуска или остановки служб во время текущего сеанса. Чтобы указать systemd автоматически запускать службы при загрузке, вы должны включить их.

Чтобы запустить службу при загрузке, используйте команду enable:

Это создаст символическую ссылку из системной копии служебного файла (обычно в /lib/systemd/system или /etc/systemd/system ) на место на диске, где systemd ищет файлы автозапуска (обычно /etc/ systemd/system/ some_target .target.wants . Что такое цель, мы рассмотрим позже в этом руководстве).

Чтобы отключить автоматический запуск службы, введите:

Это удалит символическую ссылку, указывающую, что служба должна запускаться автоматически.

Имейте в виду, что включение службы не запускает ее в текущем сеансе. Если вы хотите запустить службу, а также включить ее при загрузке, вам придется выполнить обе команды запуска и включения.

Проверка статуса служб

Чтобы проверить статус службы в вашей системе, вы можете использовать команду status:

Это предоставит вам состояние службы, иерархию cgroup и первые несколько строк журнала.

Например, при проверке состояния сервера Nginx вы можете увидеть такой вывод:

Это дает вам хороший обзор текущего состояния приложения, уведомляя вас о любых проблемах и любых действиях, которые могут потребоваться.

Существуют также методы проверки определенных состояний. Например, чтобы проверить, активен ли юнит в данный момент (работает), вы можете использовать команду is-active:

Это вернет текущее состояние объекта, которое обычно активно или неактивно. Код выхода будет «0», если он активен, что упрощает анализ результата в сценариях оболочки.

Чтобы узнать, включено ли устройство, вы можете использовать команду is-enabled:

Это покажет, включена или отключена служба, и снова установит код выхода «0» или «1» в зависимости от ответа на командный вопрос.

Третья проверка — находится ли устройство в неисправном состоянии. Это указывает на то, что возникла проблема с запуском рассматриваемого устройства:

Это вернет активное значение, если оно работает правильно, или сбой, если произошла ошибка. Если устройство было намеренно остановлено, оно может вернуть unknown или inactive . Статус выхода "0" означает, что произошел сбой, а статус выхода "1" указывает на любой другой статус.

Обзор состояния системы

Команды до сих пор были полезны для управления отдельными службами, но они не очень полезны для изучения текущего состояния системы. Эту информацию предоставляют несколько команд systemctl.

Список текущих единиц

Чтобы увидеть список всех активных юнитов, о которых знает systemd, мы можем использовать команду list-units:

Это покажет вам список всех юнитов, которые systemd в данный момент активны в системе. Вывод будет выглядеть примерно так:

Вывод содержит следующие столбцы:

  • UNIT: название подразделения systemd.
  • ЗАГРУЗКА: была ли конфигурация устройства проанализирована systemd. Конфигурация загруженных объектов сохраняется в памяти.
  • АКТИВЕН: сводка о том, активен ли объект. Обычно это довольно простой способ определить, успешно ли запущено устройство.
  • SUB: это состояние более низкого уровня, которое указывает более подробную информацию об устройстве. Это часто зависит от типа модуля, состояния и фактического метода, в котором работает модуль.
  • ОПИСАНИЕ: краткое текстовое описание того, чем является/делает устройство.

Поскольку команда list-units по умолчанию показывает только активные юниты, все записи выше будут отображаться как загруженные в столбце LOAD и активные в столбце ACTIVE. Это отображение на самом деле является поведением systemctl по умолчанию при вызове без дополнительных команд, поэтому вы увидите то же самое, если вызовете systemctl без аргументов:

Мы можем указать systemctl выводить другую информацию, добавив дополнительные флаги. Например, чтобы увидеть все юниты, которые systemd загрузил (или пытался загрузить), независимо от того, активны ли они в данный момент, вы можете использовать флаг --all, например:

Это покажет любой юнит, который systemd загрузил или пытался загрузить, независимо от его текущего состояния в системе. Некоторые юниты становятся неактивными после запуска, а некоторые юниты, которые systemd пыталась загрузить, возможно, не были найдены на диске.

Вы можете использовать другие флаги для фильтрации этих результатов. Например, мы можем использовать флаг --state=, чтобы указать состояния LOAD, ACTIVE или SUB, которые мы хотим видеть.Вам придется сохранить флаг --all, чтобы systemctl позволял отображать неактивные юниты:

Другим распространенным фильтром является фильтр --type=. Мы можем указать systemctl отображать только единицы интересующего нас типа. Например, чтобы увидеть только активные единицы обслуживания, мы можем использовать:

Список всех файлов модулей

Команда list-units отображает только единицы, которые systemd пыталась проанализировать и загрузить в память. Поскольку systemd будет считывать только те модули, которые, по его мнению, ему нужны, это не обязательно будет включать все доступные модули в системе. Чтобы увидеть каждый доступный модульный файл в путях systemd, включая те, которые systemd не пытался загрузить, вместо этого вы можете использовать команду list-unit-files:

Единицы — это представления ресурсов, о которых знает systemd. Поскольку systemd не обязательно считывает все определения юнитов в этом представлении, он предоставляет информацию только о самих файлах. Вывод имеет два столбца: файл модуля и состояние.

Состояние обычно бывает включенным, отключенным, статическим или замаскированным. В этом контексте статический означает, что файл модуля не содержит раздела установки, который используется для включения модуля. Таким образом, эти единицы не могут быть включены. Обычно это означает, что модуль выполняет разовое действие или используется только как зависимость от другого модуля и не должен запускаться сам по себе.

Сейчас мы рассмотрим, что означает маска.

Управление объектами

До сих пор мы работали со службами и отображали информацию о юнитах и ​​юнит-файлах, о которых знает systemd. Однако мы можем узнать более конкретную информацию о юнитах с помощью некоторых дополнительных команд.

Отображение файла модуля

Чтобы отобразить файл модуля, который systemd загрузил в свою систему, вы можете использовать команду cat (она была добавлена ​​в systemd версии 209). Например, чтобы просмотреть модульный файл демона планирования atd, можно ввести:

Выходным файлом является юнит-файл, известный текущему запущенному процессу systemd. Это может быть важно, если вы недавно изменяли юнит-файлы или если вы переопределяете определенные параметры во фрагменте юнит-файла (мы рассмотрим это позже).

Отображение зависимостей

Чтобы увидеть дерево зависимостей объекта, вы можете использовать команду list-dependencies:

Это отобразит иерархию, отображающую зависимости, с которыми необходимо иметь дело, чтобы запустить рассматриваемый модуль. Зависимости в этом контексте включают те модули, которые либо требуются, либо требуются вышестоящим модулям.

Рекурсивные зависимости отображаются только для единиц .target, которые указывают состояния системы. Чтобы рекурсивно вывести список всех зависимостей, включите флаг --all.

Чтобы отобразить обратные зависимости (единицы, зависящие от указанной единицы), можно добавить в команду флаг --reverse. Другими полезными флагами являются флаги --before и --after, которые можно использовать для отображения юнитов, которые зависят от указанного юнита, начинающегося до и после себя соответственно.

Проверка свойств объекта

Чтобы просмотреть низкоуровневые свойства объекта, вы можете использовать команду show. Это отобразит список свойств, заданных для указанного объекта в формате ключ=значение:

Если вы хотите отобразить одно свойство, вы можете передать флаг -p с именем свойства. Например, чтобы просмотреть конфликты модуля sshd.service, введите:

Маскирование и демаскирование юнитов

В разделе управления службами мы видели, как остановить или отключить службу, но systemd также имеет возможность пометить единицу как полностью не запускаемую автоматически или вручную, связав ее с /dev/ нулевой . Это называется маскированием объекта и возможно с помощью команды mask:

Это предотвратит запуск службы Nginx автоматически или вручную, пока она маскируется.

Если вы проверите list-unit-files , вы увидите, что служба теперь указана как замаскированная:

Если вы попытаетесь запустить службу, вы увидите следующее сообщение:

Чтобы размаскировать юнит, сделав его снова доступным для использования, используйте команду unmask:

Это вернет устройство в его предыдущее состояние, что позволит запустить или включить его.

Редактирование файлов объектов

Хотя конкретный формат юнит-файлов выходит за рамки этого руководства, systemctl предоставляет встроенные механизмы для редактирования и изменения юнит-файлов, если вам нужно внести коррективы. Эта функция была добавлена ​​в systemd версии 218.

Команда редактирования по умолчанию открывает фрагмент файла объекта для рассматриваемого объекта:

Это будет пустой файл, который можно использовать для переопределения или добавления директив в определение устройства. В каталоге /etc/systemd/system будет создан каталог, содержащий имя устройства с добавлением .d. Например, для nginx.service будет создан каталог с именем nginx.service.d.

В этом каталоге будет создан фрагмент с именем override.conf .Когда юнит загружен, systemd в памяти объединит фрагмент переопределения с полным файлом юнита. Директивы фрагмента будут иметь приоритет над теми, которые находятся в исходном файле модуля.

Если вы хотите отредактировать весь файл модуля вместо создания фрагмента, вы можете передать флаг --full:

Это загрузит текущий файл модуля в редактор, где его можно изменить. Когда редактор закроется, измененный файл будет записан в /etc/systemd/system, что будет иметь приоритет над определением модуля системы (обычно находится где-то в /lib/systemd/system).

Чтобы удалить любые сделанные вами дополнения, удалите каталог конфигурации .d устройства или измененный служебный файл из /etc/systemd/system. Например, чтобы удалить фрагмент, мы можем ввести:

Чтобы удалить полностью измененный файл модуля, введите:

После удаления файла или каталога вы должны перезагрузить процесс systemd, чтобы он больше не пытался ссылаться на эти файлы и вернулся к использованию системных копий. Вы можете сделать это, набрав:

Настройка состояния системы (уровня запуска) с помощью целей

Цели — это специальные файлы модулей, описывающие состояние системы или точку синхронизации. Как и другие модули, файлы, определяющие цели, можно идентифицировать по суффиксу, в данном случае — .target. Цели сами по себе мало что делают, вместо этого они используются для группировки других юнитов.

Это можно использовать для приведения системы в определенные состояния, подобно тому, как другие системы инициализации используют уровни выполнения. Они используются в качестве справки, когда доступны определенные функции, что позволяет указать желаемое состояние вместо отдельных единиц, необходимых для создания этого состояния.

Например, существует swap.target, который указывает, что swap готов к использованию. Единицы, которые являются частью этого процесса, могут синхронизироваться с этой целью, указав в своей конфигурации, что они WantedBy= или RequiredBy= swap.target . Единицы, для которых требуется замена, могут указать это условие, используя спецификации Wants= , Requires= и After= , чтобы указать характер их взаимосвязи.

Получение и установка цели по умолчанию

У процесса systemd есть цель по умолчанию, которую он использует при загрузке системы. Удовлетворение каскада зависимостей от этой единственной цели приведет систему в желаемое состояние. Чтобы найти цель по умолчанию для вашей системы, введите:

Если вы хотите установить другую цель по умолчанию, вы можете использовать set-default . Например, если у вас установлен графический рабочий стол и вы хотите, чтобы система загружалась в него по умолчанию, вы можете соответствующим образом изменить цель по умолчанию:

Список доступных целей

Вы можете получить список доступных целей в вашей системе, набрав:

В отличие от уровней запуска несколько целей могут быть активны одновременно. Активная цель указывает на то, что systemd попытался запустить все юниты, привязанные к цели, и не пытался их снова отключить. Чтобы просмотреть все активные цели, введите:

Изоляция целей

Можно запустить все модули, связанные с целью, и остановить все модули, не входящие в дерево зависимостей. Команда, которая нам нужна для этого, называется isolate. Это похоже на изменение уровня выполнения в других системах инициализации.

Например, если вы работаете в графической среде с активным graphical.target, вы можете выключить графическую систему и перевести систему в состояние многопользовательской командной строки, изолировав multi-user.target . Поскольку graphical.target зависит от multi-user.target, а не наоборот, все графические блоки будут остановлены.

Возможно, вы захотите взглянуть на зависимости цели, которую вы изолируете, прежде чем выполнять эту процедуру, чтобы убедиться, что вы не останавливаете жизненно важные службы:

Когда вас устраивают юниты, которые останутся в живых, вы можете изолировать цель, набрав:

Использование ярлыков для важных событий

Для важных событий, таких как выключение или перезагрузка, определены цели. Однако в systemctl также есть несколько сокращений, добавляющих дополнительные функциональные возможности.

Например, чтобы перевести систему в режим спасения (однопользовательский), вы можете использовать команду восстановления вместо команды isolate save.target :

Это обеспечит дополнительную функциональность оповещения всех вошедших в систему пользователей о событии.

Чтобы остановить систему, вы можете использовать команду halt:

Чтобы инициировать полное отключение, вы можете использовать команду poweroff:

Перезапуск можно запустить с помощью команды reboot:

Все эти оповещения регистрируют пользователей о том, что происходит событие, чего нельзя сделать только при запуске или изоляции цели. Обратите внимание, что большинство машин связывают более короткие и традиционные команды для этих операций, чтобы они правильно работали с systemd .

Например, чтобы перезагрузить систему, обычно можно ввести:

Заключение

К настоящему времени вы должны быть знакомы с некоторыми основными возможностями команды systemctl, которые позволяют вам взаимодействовать с вашим экземпляром systemd и управлять им. Утилита systemctl будет вашей основной точкой взаимодействия для управления сервисом и состоянием системы.

Хотя systemctl работает в основном с основным процессом systemd, в экосистеме systemd есть и другие компоненты, которые контролируются другими утилитами. Другие возможности, такие как управление журналами и пользовательские сеансы, обрабатываются отдельными демонами и утилитами управления (Journald/Journalctl и Logind/loginctl соответственно). Ознакомление с другими инструментами и демонами поможет упростить управление.

Хотите узнать больше? Присоединяйтесь к сообществу DigitalOcean!

Присоединяйтесь к нашему сообществу DigitalOcean, насчитывающему более миллиона разработчиков, бесплатно! Получайте помощь и делитесь знаниями в нашем разделе "Вопросы и ответы", находите руководства и инструменты, которые помогут вам расти как разработчику и масштабировать свой проект или бизнес, а также подписывайтесь на интересующие вас темы.

Читайте также: