Управление службами systemd. часть 1 из 3. категория: ос linux • разное

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Для запуска службы во время загрузки используйте команду :

При этом будет создана символическая ссылка из системной копии служебного файла (обычно в или ) в месте на диске, где ищет файлы для автозапуска (обычно ; что такое цель, мы рассмотрим далее в этом руководстве).

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

При этом будет удалена символическая ссылка, что укажет на то, что служба не должна запускаться автоматически.

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

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

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

При этом вы получите статус службы, иерархию контрольных групп и первые несколько строк журнала.

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

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

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

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

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

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

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

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

Editing Unit Files

While the specific format for unit files is outside of the scope of this tutorial, provides built-in mechanisms for editing and modifying unit files if you need to make adjustments. This functionality was added in version 218.

The command, by default, will open a unit file snippet for the unit in question:

This will be a blank file that can be used to override or add directives to the unit definition. A directory will be created within the directory which contains the name of the unit with appended. For instance, for the , a directory called will be created.

Within this directory, a snippet will be created called . When the unit is loaded, will, in memory, merge the override snippet with the full unit file. The snippet’s directives will take precedence over those found in the original unit file.

If you wish to edit the full unit file instead of creating a snippet, you can pass the flag:

This will load the current unit file into the editor, where it can be modified. When the editor exits, the changed file will be written to , which will take precedence over the system’s unit definition (usually found somewhere in ).

To remove any additions you have made, either delete the unit’s configuration directory or the modified service file from . For instance, to remove a snippet, we could type:

To remove a full modified unit file, we would type:

After deleting the file or directory, you should reload the process so that it no longer attempts to reference these files and reverts back to using the system copies. You can do this by typing:

Writing user units

See for general information about writing systemd unit files.

Example

The following is an example of a user version of the mpd service:

~/.config/systemd/user/mpd.service

Description=Music Player Daemon


ExecStart=/usr/bin/mpd --no-daemon


WantedBy=default.target

Example with variables

The following is an example of a user version of , which takes into account variable home directories where SickBeard can find certain files:

~/.config/systemd/user/sickbeard.service

Description=SickBeard Daemon


ExecStart=/usr/bin/env python2 /opt/sickbeard/SickBeard.py --config %h/.sickbeard/config.ini --datadir %h/.sickbeard


WantedBy=default.target

As detailed in , the variable is replaced by the home directory of the user running the service. There are other variables that can be taken into account in the systemd manpages.

Reading the journal

The journal for the user can be read using the analogous command:

$ journalctl --user

To specify a unit, one can use

$ journalctl --user-unit myunit.service

Or, equivalently:

$ journalctl --user -u myunit.service

Создание юнитов

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

mcedit /etc/systemd/system/test.service

В описании юнита добавьте обязательные секции:

 
Description=test service 
 
Type=oneshot ExecStart=/bin/echo "Hello World!" RemainAfterExit=yes

WantedBy=multi-user.target

Теперь нужно применить изменения в конфигурации:

Следующий шаг — запуск юнита:

Напоследок проверьте его статус:

Навык создания юнитов пригодится и разработчикам, и системным администраторам для установки ПО. Например, в Apache Kafka для управления состоянием кластера и конфигурациями используется служба . Для нее нужно создавать юнит. И подобные задачи возникают достаточно часто.

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

Kill user processes on logout

Arch Linux builds the package with , setting to by default. This setting causes user processes not to be killed when the user logs out. To change this behavior in order to have all user processes killed on the user’s logout, set in .

Note that changing this setting breaks terminal multiplexers such as tmux and GNU Screen. If you change this setting, you can still use a terminal multiplexer by using as follows:

$ systemd-run --scope --user command args

For example, to run you would do:

$ systemd-run --scope --user screen -S foo

Using will keep the process running after logout only while the user is logged in at least once somewhere else in the system and is still running.

Systemd: управление автозагрузкой служб в Linux

В большистве популярных современных популярных дистрибутивов Linux (CentOS 7, RHEL, Debian, Fedora и Ubuntu) в качестве демона автозагрузки вместо init.d используется systemd. Systemd – менеджер системы и служб Linux, используется для запуска других демонов и управления ими в процессе работы, использует unit-файлы из /etc/systemd/system (init.d использовал скрипты из каталога /etc/init.d/). Systemd позволяет распараллелить запуск служб в процессе загрузки ОС, тем самым ускоряя запуск.

Для управления system используется команда systemctl.

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

Список unit-файлов можно получить командой:

Данная команда отобразит все доступные юнит-файлы (не зависимо от того, были они загружены в systemd после загрузки ОС или нет).

Чтобы вывести список активных сервисов и их состояние, выполните:

Следующая команда выведет список юнитов, которые загрузил или пытался загрузить systemd. Так как после запуска некоторые юниты могут стать неактивными, с помощью флага —all вы получите полный список.

UNIT LOAD ACTIVE SUB DESCRIPTION
proc-sys-fs-binfmt_misc.automount loaded active waiting ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
● exim.service not-found inactive dead exim.service
firewalld.service loaded active running firewalld - dynamic firewall daemon
getty@tty1.service loaded active running Getty on tty1
● ip6tables.service not-found inactive dead ip6tables.service
● ipset.service not-found inactive dead ipset.service
● iptables.service not-found inactive dead iptables.service
Bring up/down networking
● NetworkManager-wait-online.service not-found inactive dead

Как видим из списка, здесь отображаются даже сервисы, которые не были найдены на диске «not-found».

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

—state — используется для определения состояния демона Load, Active, Sub
—type — позволяет фильтровать юниты по их типу.

Примеры:

— выведет список только активных юнитов

— выведет список юнитов, которые являются сервисом.

Добавление сервиса в systemd

Для управления сервисами в systemd используется особый синтаксис. После имени серверсв в конце нужно указывать .service. Например:

– команда добавит в автозагрузку веб-сервер nginx

Данная команда создаст символическую ссылку на копию файла, указанного в команде сервиса, в директории автозапуска systemd.

Created symlink from /etc/systemd/system/multi-user.target.wants/nginx.service to /usr/lib/systemd/system/nginx.service

Вывод этой команды показывает в какой директории был создан симлинк на файл сервиса.

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

При выводе нужно обратить внимание на строку:

Loaded: loaded (/usr/lib/systemd/system/nginx.service; enabled; vendor preset: disabled)

Значение enabled означает что данный сервис загружается автоматически (добавлен в автозагрузку). Если сервис не загружается автоматом, здесь буде указано disabled.

Удаление сервиса из systemd

Вы можете удалить сервис из автозагрузки, чтобы он не запускался после старта Linux (при этом сам сервис с сервера не удаляется). Чтобы удалить сервис из автозагрузки, выполните команду:

Например, чтобы удалить из автозагрузки nginx, выполните:

Removed symlink /etc/systemd/system/multi-user.target.wants/nginx.service

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

Systemd: маскировка юнитов

В моей практике встречались «вредные» сервисы, которые после удаления их из автозагрузки, все равно там оставались и запускались после рестарта ОС. Чтобы решить этот вопрос, можно замаскировать сервис:

И после этого, он вообще не будет запускаться, ни вручную, ни после перезагрузки ОС:

Created symlink from /etc/systemd/system/nginx.service to /dev/null.

Redirecting to /bin/systemctl restart nginx.service
Failed to restart nginx.service: Unit is masked.

Снять маску можно командой:

Removed symlink /etc/systemd/system/nginx.service.

Если после маскировки сервиса, вы проверите юнит-файлы, то увидите, что сервис помечен как замаскированный (состояние masked):

Таким нехитрым способом, можно избавить себя от удаления сервиса, даже если он не удаляется из автозагрузки systemd.

Configure user space processes to continue after logout

By default, services and processes that are started and owned by a user are terminated when the user logs out or when all sessions for the user have terminated. There are several methods that you can use to change this default behavior within systemd. Two options are explored here.

Use the loginctl command to enable systemd linger users

The loginctl command can be used to change the default behavior for a specific user and to enable processes for that user to ‘linger’ after the user’s session is terminated.

Use the loginctl utility to enable linger for a specific user. In this instance, enable the systemd linger behavior for the ‘oracle’ user:
To verify that the setting is applied, check for a file with the same name as the user in the directory.

The command should verify that the file exists.

Edit the systemd logind.conf file

Systemd manages user login events and provides a configuration file that can be edited to set default behavior for different events related to the user’s session. This configuration file is located at .

Dump the contents of the existing configuration at to the screen to review:

The majority of options are commented out but display the compile time default values. There are three options in this file that can control how systemd handles processes running in user space when the user’s session terminates.
- : this option can control whether or not user processes are terminated by default when the session ends. Setting this option to ‘no’ allows systemd to run user processes after any user logs out of the system.
- : If the option is enabled, this option allows you to specify a space separated list of users for which systemd allows processes to continue to run after the session terminates. Adding a username to this list behaves similarly to adding a user to the systemd linger group using the loginctl command.
- : If the option is disabled, this parameter can be used to specify a space separated list of users for which processes should be terminated after logout.

Systemd — управление автозагрузкой служб в Linux

В большистве популярных современных популярных дистрибутивов Linux (CentOS, RHEL, Debian, Fedora и Ubuntu) в качестве демона автозагрузки вместо init.d используется systemd.

Systemd – менеджер системы и служб Linux, используется для запуска других демонов и управления ими в процессе работы, использует unit-файлы из /etc/systemd/system (init.d использовал скрипты из каталога /etc/init.d/). Systemd позволяет распараллелить запуск служб в процессе загрузки ОС, тем самым ускоряя запуск.

Для управления system используется команда systemctl.

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

Список unit-файлов можно получить командой:

Чтобы вывести список активных сервисов и их состояние, выполните:

Следующая команда выведет список юнитов, которые загрузил или пытался загрузить systemd. Так как после запуска некоторые юниты могут стать неактивными, с помощью флага — all вы получите полный список.

Добавление сервиса в systemd

команда добавит в автозагрузку веб-сервер nginx

Вывод этой команды показывает в какой директории был создан симлинк на файл сервиса.

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

При выводе нужно обратить внимание на строку:

Удаление сервиса из systemd

Например, чтобы удалить из автозагрузки nginx, выполните:

Systemd — маскировка юнитов

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

И после этого он вообще не будет запускаться:

Снять маску можно командой:

Если после маскировки сервиса, вы проверите юнит-файлы, то увидите, что сервис помечен как замаскированный (состояние masked).

Step 5: Verify the systemd unit file configuration

Now since we are done with the setting up of systemd. Let us verify our configuration. Before starting I have cleared the content of which is where our script will place dummy content every minutes for 3 minutes.

We will only start the runtime as a reboot is not required to validate the configuration here:

# systemctl restart run-as-user.service

Next check the status of the service

# systemctl status run-as-user.service
● run-as-user.service - Run service as user deepak
   Loaded: loaded (/etc/systemd/system/run-as-user.service; enabled; vendor preset: disabled)
   Active: active (exited) since Fri 2020-01-17 02:09:32 IST; 2h 31min ago
  Process: 24113 ExecStart=/tmp/startup_script.sh (code=exited, status=0/SUCCESS)
 Main PID: 24113 (code=exited, status=0/SUCCESS)

Jan 17 02:09:32 centos-8.example.com systemd: Started Run service as user deepak.

Well looks like everything was good as we were able to run systemd service as specific user and group, you can check the status to make sure our script is running using below command:

# ps -ef | grep startup
deepak   26877     1  0 04:42 ?        00:00:00 /bin/bash /tmp/startup_script.sh
root     26890  7625  0 04:42 pts/0    00:00:00 grep --color=auto startup

Now you can monitor the content of for couple of minutes as configured in the script

# cat /tmp/file
startup_script.sh: finished minute 1
startup_script.sh: finished minute 2
startup_script.sh: finished minute 3
startup_script.sh: COMPLETELY FINISHED

Lastly I hope the steps from the article to run systemd service as specific user and group in CentOS/RHEL 7/8 Linux was helpful. So, let me know your suggestions and feedback using the comment section.

Related Searches: run service as user linux. systemd allow user to start service. systemd start service as user on boot. linux systemd service run as root. Restarting systemd service only as a specific user? systemd services fail with User= in service file. Start process as a specific user. how to run a service a non-root user completely?

Структура юнита systemd

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

Для наглядности посмотрите на пример юнита sshd:

Description=OpenSSH server daemon
Documentation=man:sshd(8) man:sshd_config(5)
After=network.target sshd-keygen.target
Wants=sshd-keygen.target
 

Type=notify
EnvironmentFile=-/etc/crypto-policies/back-ends/opensshserver.config
EnvironmentFile=-/etc/sysconfig/sshd
ExecStart=/usr/sbin/sshd -D $OPTIONS $CRYPTO_POLICY
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
Restart=on-failure
RestartSec=42s
 

WantedBy=multi-user.target

Давайте разберем все секции.

Unit

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

— короткое описание демона.
— страница man, на которой расписан порядок взаимодействия со службой.
— указание на то, после каких демонов и событий демон запускается. Например, юнит поднимается после запуска сетевых интерфейсов. Можно указать целую группу других сервисов.
— какой сервис необходим для запуска юнита.
— какой сервис желательно запустить перед стартом юнита.

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

Пример оформления секции :

Description=MyUnit
After=syslog.target
After=network.target
After=nginx.service
After=mysql.service
Requires=mysql.service
Wants=redis.service

Service

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

— описывает, как запустится демон. Есть несколько вариантов: (по умолчанию) — ожидает, что служба запустится незамедлительно. Процесс не должен разветвляться. — после запуска демон ответвляется (делает форк), родительский процесс завершается. Такой подход используется для запуска классических демонов. — одноразовое выполнение. Используется для скриптов, которые запускаются и завершаются после выполнения. — аналог , но в этом случае сам процесс сообщит systemd о том, что он закончил загрузку и готов к работе.
— ссылка на основной процесс, который отслеживает systemd.
— рабочая директория. Становится текущей перед запуском стартап команд.
— пользователь, под которым надо запускать сервис.
— группа, под которой надо запускать сервис.
— переменная окружения.
— запрет на убийство сервиса из-за нехватки памяти или срабатывания механизма OOM (-1000 — полный запрет).
— команда для старта сервиса.
— команда для перезапуска сервиса.
— команда для остановки сервиса.
— время в секундах, которое сервис ожидает отработки старт- или стоп-команд.
— настройки перезапуска.

Пример оформления секции :

Type=forking
PIDFile=/work/www/myunit/shared/tmp/pids/service.pid
WorkingDirectory=/work/www/myunit/current
User=myunit
Group=myunit
Environment=RACK_ENV=production
OOMScoreAdjust=-1000
ExecStart=/usr/local/bin/bundle exec service -C /work/www/myunit/shared/config/service.rb --daemon
ExecStop=/usr/local/bin/bundle exec service -S /work/www/myunit/shared/tmp/pids/service.state stop
ExecReload=/usr/local/bin/bundle exec service -S /work/www/myunit/shared/tmp/pids/service.state restart
TimeoutSec=300

Install

Третья обязательная секция. В ней описывается на каком уровне запуска стартует настраиваемый сервис.

Переменная сообщает, как устройство включится. Например, означает, что при запуске в директории /// появится каталог . В нем будет ссылка на службу, которая удалится после остановки службы.

Пример оформления секции :

WantedBy=multi-user.target

Перечень доступных параметров указан в руководстве. Вызвать его можно командой:

Для определения того, какие сервисы и в каком порядке будут загружены, используется . Его основные виды:

– отключение системы;
– режим восстановления, однопользовательский (init 1);
– сетевой режим без графической оболочки, (init 3);
– сетевой режим с графической оболочкой (init 5);
– перезагрузка;
– аварийная командная строка, минимальный функционал.

Цели могут наследоваться. Пример взаимодействия с ними:

#список целей
systemctl list-units --type=target
#перейти в нужную цель (например – загрузится из сетевого режима в графический)
systemctl isolate graphical.target
#выбрать target по умолчанию
systemctl set-default multi-user.target

Файлы юнитов и зависимости

Файл юнита содержит параметры, используемые systemd для запуска и управления. Для просмотра полного содержимого файла юнита нужно выполнить команду:

systemctl cat nginx.service

Для просмотра дерева зависимостей юнита (другие юниты, активируемые systemd при запуске юнита), выполните команду:

systemctl list-dependencies nginx.service

Вывод списка зависимых юнитов, которые будут рекурсивно раскрыты. Для полного рекурсивного раскрытия всех зависимых юнитов (второй и большие уровни зависимости), воспользуйтесь опцией —all:

systemctl list-dependencies --all nginx.service

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

systemctl show nginx.service

Основы управления сервисами (юнитами)

Базовый объект, с которым работает systemd, называется “юнитом” (unit). Есть много видов юнитов, но самым распространенным является служба (service, файл юнита заканчивается на .service). Основным инструментом для управления службами на сервере является команда systemctl.

У всех команд обычной системы инициализации есть эквиваленты в systemctl. В примерах мы будем использовать службу nginx.service. Если у вас её нет, установите ее при помощи менеджера пакетов.

Для запуска службы нужно ввести:

systemctl start nginx.service

Остановка осуществляется следующей командой:

systemctl stop nginx.service

Перезапуск службы:

systemctl restart nginx.service

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

systemctl reload nginx.service

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

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

Список текущих модулей

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

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

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

UNIT: имя модуля
LOAD: указывает на то, парсила ли конфигурацию модуля. Конфигурация загруженных модулей сохраняется в памяти.
ACTIVE: краткое состояние активности модуля. Обычно это довольно стандартный способ сообщить, запущен модуль или нет.
SUB: это состояние более низкого уровня, которое указывает более подробную информацию о модуле. Это часто зависит от типа модуля, состояния и фактического метода работы модуля.
DESCRIPTION: краткое текстовое описание того, чем является модуль/что делает.

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

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

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

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

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

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

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

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

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

Мы рассмотрим сразу же, что означает .

Сравнение SysV и systemd

Функции	SysV	systemd
Зависимость D-Bus	Нет	Да
Управление устройствами с помощью udev	Нет	Да
Активация по таймеру	cron/at	Проприетарная
Управление квотами	Нет	Да
Автоматическая обработка зависимостей служб	Нет	Да
Завершение процессов пользователей при выходе из системы	Нет	Да
Управление пространством подкачки	Нет	Да
Интеграция SELinux	Нет	Да
Поддержка шифрованных HDD	Нет	Да
Загрузка статических модулей ядра	Нет	Да
Графический интерфейс пользователя (GUI)	Нет	Да
Перечисление всех дочерних процессов	Нет	Да
Совместимость с SysV	Да	Да
Интерактивная загрузка	Нет	Да
Переносимость на отличную от x86 архитектуру процессора	Да	Нет
Параллельный запуск служб	Нет	Да
Ограничение ресурсов для каждой службы	Нет	Да
Легко расширяемый скрипт автозагрузки	Да	Нет
Раздельные код и файл конфигурации	Да	Нет
Автоматический расчет зависимостей	Нет	Да
Подробный вывод отладочной информации	Да	Нет
Количество файлов	75 файлов	900 файлов + Glib + D-Bus

Заключение

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

Хотя работает главным образом с основным процессом , в экосистеме есть другие компоненты, которые контролируются другими утилитами. Другие возможности, такие как управление журналами и сеансы пользователя, обрабатываются отдельными демонами и утилитами управления (/ и / соответственно). Знакомство с этими другими инструментами и демонами упростит задачу управления.