Управление службами в Red Hat Enterprise Linux

Введение

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

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

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

На этом этапе вы научитесь определять автоматически запущенные системные процессы с помощью команды systemctl. systemctl — это основной инструмент для управления службами systemd в Red Hat Enterprise Linux.

Сначала давайте узнаем, как вывести список всех загруженных и активных модулей служб (service units). Для этого используется команда systemctl list-units --type=service. Она отображает те службы, которые демон systemd успешно проанализировал, загрузил в память и которые в данный момент активны.

Откройте терминал в среде RHEL. Вы уже вошли в систему как пользователь labex, а ваша текущая директория — ~/project.

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

systemctl list-units --type=service

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

UNIT                  LOAD    ACTIVE  SUB      DESCRIPTION
atd.service           loaded  active  running  Job spooling tools
auditd.service        loaded  active  running  Security Auditing Service
chronyd.service       loaded  active  running  NTP client/server
crond.service         loaded  active  running  Command Scheduler
dbus-broker.service   loaded  active  running  D-Bus System Message Bus
...output omitted...

Разберем столбцы вывода:

UNIT: Имя модуля службы, обычно заканчивающееся на .service.
LOAD: Указывает, успешно ли демон systemd проанализировал конфигурацию модуля и загрузил её в память. loaded означает успех.
ACTIVE: Высокоуровневое состояние активации модуля. active обычно означает, что служба успешно запущена.
SUB: Низкоуровневое состояние активации, предоставляющее более детальную информацию. Для работающих служб часто встречается running.
DESCRIPTION: Краткое описание того, что делает служба.

Нажмите q, чтобы выйти из команды.

Далее вы можете использовать опцию --all вместе с systemctl list-units --type=service, чтобы вывести список всех служб независимо от их состояния (активные, неактивные, с ошибками и т.д.). Это полезно для просмотра служб, которые установлены, но в данный момент не запущены.

Выполните следующую команду:

systemctl list-units --type=service --all

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

UNIT                          LOAD      ACTIVE   SUB     DESCRIPTION
  atd.service                 loaded    active   running Job spooling tools
  auditd.service              loaded    active   running Security Auditing ...
  auth-rpcgss-module.service  loaded    inactive dead    Kernel Module ...
  chronyd.service             loaded    active   running NTP client/server
  cpupower.service            loaded    inactive dead    Configure CPU power ...
  crond.service               loaded    active   running Command Scheduler
  dbus-broker.service         loaded    active   running  D-Bus System Message Bus
● display-manager.service     not-found inactive dead    display-manager.service
...output omitted...

Наконец, чтобы увидеть состояние всех установленных файлов модулей, включая те, что не загружены или не активны, можно использовать systemctl list-unit-files --type=service. Эта команда показывает, является ли служба enabled (запускается при загрузке), disabled (не запускается при загрузке), static (не может быть включена напрямую, но может быть запущена другим модулем) или masked (запуск предотвращен).

Выполните следующую команду:

systemctl list-unit-files --type=service

Вы увидите вывод, похожий на этот, с указанием STATE (состояния) и VENDOR PRESET (предустановки поставщика) для каждого файла службы:

UNIT FILE                         STATE       VENDOR PRESET
arp-ethers.service                disabled    disabled
atd.service                       enabled     enabled
auditd.service                    enabled     enabled
auth-rpcgss-module.service        static      -
autovt@.service                   alias       -
blk-availability.service          disabled    disabled
...output omitted...

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

Проверка состояния конкретной службы с помощью systemctl status

На этом этапе вы научитесь проверять подробное состояние конкретной службы с помощью команды systemctl status. Эта команда предоставляет исчерпывающую информацию о службе, включая то, запущена ли она, её идентификатор процесса (PID), использование памяти и последние записи в журнале.

В качестве примера мы будем использовать crond.service (демон cron). Демон cron — это распространенная служба, которая обрабатывает запланированные задачи.

Откройте терминал в среде RHEL. Убедитесь, что вы находитесь в директории ~/project.

Выполните следующую команду, чтобы проверить состояние crond.service:

systemctl status crond.service

Вы увидите подробный вывод, похожий на этот:

● crond.service - Command Scheduler
     Loaded: loaded (/usr/lib/systemd/system/crond.service; enabled; preset: enabled)
     Active: active (running) since Mon 2022-03-14 05:38:10 EDT; 25min ago
   Main PID: 1089 (crond)
      Tasks: 1 (limit: 35578)
     Memory: 1.2M
        CPU: 12ms
     CGroup: /system.slice/crond.service
             └─1089 /usr/sbin/crond -n

Mar 14 05:38:10 workstation systemd[1]: Started Command Scheduler.
Warning: some journal files were not opened due to insufficient permissions.

Давайте разберем ключевые поля вывода:

Loaded: Эта строка сообщает, был ли обработан файл конфигурации службы. Также здесь указан путь к файлу модуля (/usr/lib/systemd/system/crond.service) и статус включения (enabled означает, что служба настроена на запуск при загрузке).
Active: Это критически важное поле. Оно указывает текущее состояние службы. active (running) означает, что служба активна и её процессы запущены. Также здесь указано, как долго она активна. Другие состояния могут быть inactive (не запущена), active (exited) (завершила однократную задачу) или failed (произошла ошибка).
Main PID: Идентификатор процесса (PID) основного процесса, связанного со службой, вместе с именем команды.
Tasks: Количество задач (потоков), которые служба использует в данный момент.
Memory: Объем памяти, потребляемый службой.
CPU: Время процессора, затраченное службой.
CGroup: Информация о контрольной группе, к которой принадлежит служба, используемая для управления ресурсами.
Строки под CGroup показывают последние записи журнала, относящиеся к службе, что дает представление о её запуске и текущей активности.

Помимо systemctl status, существуют более простые команды для быстрой проверки конкретных аспектов состояния службы:

Чтобы проверить, активна ли служба:
```
systemctl is-active crond.service
```
Ожидаемый вывод:
```
active
```
Чтобы проверить, включена ли служба (настроена ли на запуск при загрузке):
```
systemctl is-enabled crond.service
```
Ожидаемый вывод:
```
enabled
```
Чтобы проверить, завершилась ли служба с ошибкой:
```
systemctl is-failed crond.service
```
Ожидаемый вывод (если работает правильно):
```
active
```
Если у службы возникли проблемы при запуске или работе, эта команда вернет failed.

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

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

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

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

Создайте новый файл модуля службы с именем mytest.service прямо в системной директории systemd с помощью nano:

sudo nano /etc/systemd/system/mytest.service

Вставьте следующее содержимое в редактор nano:

[Unit]
Description=My Test Service
After=network.target

[Service]
Type=simple
ExecStart=/bin/bash -c 'while true; do echo "$(date): My Test Service is running." >> /tmp/mytest.log; sleep 5; done'
ExecStop=/bin/bash -c 'echo "$(date): My Test Service stopped." >> /tmp/mytest.log'
Restart=on-failure

[Install]
WantedBy=multi-user.target

[Unit]: Содержит общую информацию о модуле. Description предоставляет понятное человеку имя, а After=network.target указывает, что эта служба должна запускаться после того, как сеть будет готова.
[Service]: Определяет поведение службы.
- Type=simple: Указывает на простой тип службы, где команда ExecStart является основным процессом.
- ExecStart: Команда, выполняемая при запуске службы. Здесь это цикл bash, который записывает сообщение с временной меткой в /tmp/mytest.log каждые 5 секунд.
- ExecStop: Команда, выполняемая при остановке службы. Она записывает сообщение об остановке в лог.
- Restart=on-failure: Настраивает службу на перезапуск, если она завершается с ненулевым кодом выхода.
[Install]: Содержит информацию о том, как служба должна быть установлена. WantedBy=multi-user.target означает, что эта служба должна быть запущена, когда система достигает многопользовательского уровня запуска (runlevel).

Сохраните файл, нажав Ctrl+X, затем Y для подтверждения и Enter.

Теперь перезагрузите демон systemd, чтобы он распознал новый файл службы:

sudo systemctl daemon-reload

Запуск службы

Для запуска службы используйте команду systemctl start.

Выполните следующую команду, чтобы запустить mytest.service. Обратите внимание, что нам нужно использовать sudo, так как операции systemctl обычно требуют прав суперпользователя.

sudo systemctl start mytest.service

Если команда выполнена успешно, немедленного вывода не будет.

Теперь убедитесь, что служба запущена, проверив её состояние:

systemctl status mytest.service

Вы должны увидеть вывод, указывающий, что служба находится в состоянии active (running):

● mytest.service - My Test Service
     Loaded: loaded (/etc/systemd/system/mytest.service; disabled; preset: disabled)
     Active: active (running) since ...
   Main PID: ... (bash)
      Tasks: 2 (limit: ...)
     Memory: ...
        CPU: ...
     CGroup: /system.slice/mytest.service
             ├─... /bin/bash -c "while true; do echo \"\$(date): My Test Service is running.\" >> /tmp/mytest.log; sleep 5; done"
             └─... sleep 5

...output omitted...

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

tail -f /tmp/mytest.log

Вы должны видеть новые строки, появляющиеся каждые 5 секунд, примерно так:

Tue Jul 22 09:15:09 AM CST 2025: My Test Service is running.
Tue Jul 22 09:15:14 AM CST 2025: My Test Service is running.

Нажмите Ctrl+C, чтобы выйти из tail.

Остановка службы

Для остановки работающей службы используйте команду systemctl stop.

Выполните следующую команду, чтобы остановить mytest.service:

sudo systemctl stop mytest.service

Опять же, немедленного вывода не будет.

Убедитесь, что служба остановлена:

systemctl status mytest.service

Теперь вывод должен показывать Active: inactive (dead):

○ mytest.service - My Test Service
     Loaded: loaded (/etc/systemd/system/mytest.service; disabled; preset: disabled)
     Active: inactive (dead) since ...
...output omitted...

Снова проверьте лог-файл /tmp/mytest.log. Вы должны увидеть сообщение "My Test Service stopped." и отсутствие новых сообщений "running".

tail /tmp/mytest.log

Вывод будет выглядеть примерно так:

Tue Jul 22 09:15:24 AM CST 2025: My Test Service is running.
Tue Jul 22 09:15:28 AM CST 2025: My Test Service stopped.

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

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

Выполните следующую команду, чтобы перезапустить mytest.service:

sudo systemctl restart mytest.service

Убедитесь, что служба снова запущена:

systemctl status mytest.service

Вы снова должны увидеть Active: active (running), и Main PID, скорее всего, будет новым числом, что указывает на запуск нового процесса.

● mytest.service - My Test Service
     Loaded: loaded (/etc/systemd/system/mytest.service; disabled; preset: disabled)
     Active: active (running) since ...
   Main PID: ... (bash)
      Tasks: 2 (limit: ...)
     Memory: ...
        CPU: ...
     CGroup: /system.slice/mytest.service
             ├─... /bin/bash -c "while true; do echo \"\$(date): My Test Service is running.\" >> /tmp/mytest.log; sleep 5; done"
             └─... sleep 5
...output omitted...

Проверьте лог-файл /tmp/mytest.log, чтобы убедиться, что служба возобновила запись сообщений "running".

tail -f /tmp/mytest.log

Вы должны увидеть сообщение "stopped", за которым следуют новые сообщения "running":

Tue Jul 22 09:15:28 AM CST 2025: My Test Service stopped.
Tue Jul 22 09:15:40 AM CST 2025: My Test Service is running.

Нажмите Ctrl+C, чтобы выйти из tail.

Применение изменений конфигурации к службе

На этом этапе вы узнаете о перезагрузке конфигураций служб. Некоторые службы могут применять изменения в своих конфигурационных файлах без необходимости полной перезагрузки. Это называется "перезагрузкой" (reloading) службы. Перезагрузка обычно предпочтительнее перезапуска, так как она позволяет избежать простоя службы и сохраняет существующие соединения или состояния. Когда служба перезагружается, её идентификатор процесса (PID) обычно остается прежним, в отличие от полного перезапуска, при котором PID меняется.

Мы продолжим использовать нашу службу mytest.service из предыдущего этапа. Мы изменим её поведение, а затем попытаемся перезагрузить её, чтобы увидеть, что произойдет.

Сначала убедитесь, что mytest.service запущена. Если нет, запустите её:

sudo systemctl start mytest.service

Проверьте её состояние и запишите Main PID:

systemctl status mytest.service

Теперь давайте изменим файл mytest.service, чтобы изменить сообщение, которое она записывает, и интервал. Мы изменим сообщение в логе и длительность sleep.

Откройте /etc/systemd/system/mytest.service с помощью nano:

sudo nano /etc/systemd/system/mytest.service

Измените строку ExecStart на следующую, изменив сообщение и время sleep с 5 на 2 секунды:

[Unit]
Description=My Test Service
After=network.target

[Service]
Type=simple
ExecStart=/bin/bash -c 'while true; do echo "$(date): My Test Service (reloaded) is running." >> /tmp/mytest.log; sleep 2; done'
ExecStop=/bin/bash -c 'echo "$(date): My Test Service stopped." >> /tmp/mytest.log'
Restart=on-failure

[Install]
WantedBy=multi-user.target

Сохраните файл, нажав Ctrl+X, затем Y и Enter.

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

sudo systemctl daemon-reload

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

sudo systemctl reload mytest.service

Скорее всего, вы столкнетесь с ошибкой:

Failed to reload mytest.service: Job type reload is not applicable for unit mytest.service.

Эта ошибка возникает потому, что наша простая служба не настроена на обработку запроса на перезагрузку. Чтобы служба могла быть перезагружена, её файл модуля должен содержать директиву ExecReload, которая указывает команду для перезагрузки конфигурации. Поскольку в нашей mytest.service этого нет, systemd не знает, как её перезагрузить.

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

Давайте воспользуемся reload-or-restart сейчас:

sudo systemctl reload-or-restart mytest.service

Эта команда должна выполниться успешно. Теперь снова проверьте состояние службы:

systemctl status mytest.service

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

Наконец, давайте проверим файл /tmp/mytest.log, чтобы увидеть, вступили ли изменения в силу.

tail -f /tmp/mytest.log

Вы должны видеть новое сообщение в логе "My Test Service (reloaded) is running.", появляющееся каждые 2 секунды. Нажмите Ctrl+C, чтобы выйти из tail.

Включение и отключение служб при загрузке с помощью systemctl

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

В типичной среде systemd включение службы создает символические ссылки в соответствующих конфигурационных директориях systemd (например, /etc/systemd/system/multi-user.target.wants/), которые указывают на файл модуля службы. Отключение службы удаляет эти ссылки.

Поскольку мы находимся в контейнеризированной среде, где systemd может не функционировать в полной мере в традиционном смысле, команды enable и disable могут не создавать реальные символические ссылки в директории /etc/systemd/system, которые сохраняются после перезапуска контейнера. Однако systemctl всё равно обрабатывает эти команды и обновляет своё внутреннее состояние, что мы и будем наблюдать.

Мы продолжим использовать нашу mytest.service для этой демонстрации.

Сначала убедитесь, что mytest.service остановлена после предыдущего этапа:

sudo systemctl stop mytest.service

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

Для включения службы используйте команду systemctl enable. Эта команда настраивает службу на автоматический запуск при загрузке системы.

Выполните следующую команду, чтобы включить mytest.service:

sudo systemctl enable mytest.service

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

Created symlink /etc/systemd/system/multi-user.target.wants/mytest.service → /etc/systemd/system/mytest.service.

Теперь убедитесь, что служба включена, используя systemctl is-enabled:

systemctl is-enabled mytest.service

Ожидаемый вывод:

enabled

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

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

Сначала давайте отключим её, чтобы подготовиться к демонстрации --now:

sudo systemctl disable mytest.service

Теперь включите и запустите её одновременно:

sudo systemctl enable --now mytest.service

Проверьте её состояние и статус включения:

systemctl status mytest.service
systemctl is-enabled mytest.service

Вы должны увидеть Active: active (running) в команде status и enabled в команде is-enabled.

Отключение службы

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

Выполните следующую команду, чтобы отключить mytest.service:

sudo systemctl disable mytest.service

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

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

Теперь убедитесь, что служба отключена:

systemctl is-enabled mytest.service

Ожидаемый вывод:

disabled

По аналогии с включением, вы можете объединить отключение и остановку службы, используя опцию --now. Это немедленно остановит службу и предотвратит её запуск при будущих загрузках.

sudo systemctl disable --now mytest.service

Проверьте её состояние и статус включения:

systemctl status mytest.service
systemctl is-enabled mytest.service

Вы должны увидеть Active: inactive (dead) в команде status и disabled в команде is-enabled.

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

Маскировка и разблокировка служб с помощью systemctl

На этом последнем этапе вы узнаете о маскировке (masking) и разблокировке (unmasking) служб. Маскировка службы — это мощный способ предотвратить её запуск, как вручную, так и автоматически при загрузке.

Когда вы маскируете службу, systemd создает символическую ссылку из /etc/systemd/system/<имя-службы>.service в /dev/null, фактически делая файл модуля службы недоступным для systemd. Это более сильная альтернатива disable.

Этот механизм лучше всего работает для служб, определенных в /usr/lib/systemd/system, где пакеты устанавливают свои файлы служб. Команда mask создает переопределяющий "пустой" файл в /etc/systemd/system. Однако, как вы уже обнаружили, если вы попытаетесь замаскировать службу, которую создали напрямую в /etc/systemd/system (как нашу mytest.service), команда может завершиться ошибкой, так как она спроектирована так, чтобы не перезаписывать существующий файл конфигурации, что привело бы к потере данных.

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

Сначала давайте проверим текущее состояние atd.service. Она должна быть активна и включена.

systemctl status atd.service

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

● atd.service - Deferred execution scheduler
     Loaded: loaded (/usr/lib/systemd/system/atd.service; enabled; preset: enabled)
     Active: active (running) since Tue 2025-07-22 09:13:06 CST; 22min ago
       Docs: man:atd(8)
   Main PID: 1222 (atd)
      Tasks: 1 (limit: 22509)
     Memory: 900.0K
        CPU: 5ms
     CGroup: /system.slice/atd.service
             └─1222 /usr/sbin/atd -f

Маскировка службы

Хорошей практикой является остановка службы перед её маскировкой.

sudo systemctl stop atd.service

Теперь выполните следующую команду, чтобы замаскировать atd.service:

sudo systemctl mask atd.service

Вы увидите вывод, указывающий на создание символической ссылки на /dev/null:

Created symlink /etc/systemd/system/atd.service → /dev/null.

Теперь попробуйте запустить замаскированную службу:

sudo systemctl start atd.service

Вы получите сообщение об ошибке, указывающее, что служба замаскирована:

Failed to start atd.service: Unit atd.service is masked.

Вы также можете проверить состояние службы с помощью systemctl list-unit-files:

systemctl list-unit-files --type=service | grep atd.service | tee ~/project/atd-mask-state.txt

Вывод должен показывать masked для atd.service:

atd.service                            masked      enabled

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

Разблокировка службы

Для разблокировки службы используйте команду systemctl unmask. Эта команда удаляет символическую ссылку на /dev/null, восстанавливая исходный файл службы из /usr/lib/systemd/system.

Выполните следующую команду, чтобы разблокировать atd.service:

sudo systemctl unmask atd.service

Вы увидите вывод, указывающий на удаление символической ссылки:

Removed "/etc/systemd/system/atd.service".

После разблокировки снова запустите службу, так как unmask только удаляет ссылку на /dev/null и не перезапускает службу за вас.

sudo systemctl start atd.service

Теперь проверьте состояние службы:

systemctl status atd.service

Вы должны увидеть Active: active (running), примерно так:

● atd.service - Deferred execution scheduler
     Loaded: loaded (/usr/lib/systemd/system/atd.service; enabled; preset: enabled)
     Active: active (running) since Tue 2025-07-22 09:36:10 CST; 2s ago
       Docs: man:atd(8)
   Main PID: 7372 (atd)
      Tasks: 1 (limit: 22509)
     Memory: 868.0K
        CPU: 6ms
     CGroup: /system.slice/atd.service
             └─7372 /usr/sbin/atd -f

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

Резюме

В этой лабораторной работе мы получили практический опыт управления системными службами с помощью команды systemctl, даже в контейнеризированной среде, где systemd может не быть основной системой инициализации. Мы научились выводить список всех загруженных и активных модулей служб с помощью systemctl list-units --type=service, разбираясь в столбцах UNIT, LOAD, ACTIVE и SUB для интерпретации состояний служб.

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