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

Red Hat Enterprise LinuxBeginner
Практиковаться сейчас

Введение

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

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

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

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

Сначала давайте рассмотрим, как вывести список всех загруженных и активных юнитов служб. Для этой цели используется команда 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: Информация о группе управления (control group), к которой принадлежит служба, используемой для управления ресурсами.
  • Строки ниже 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 означает, что эта служба должна запускаться, когда система достигает уровня выполнения multi-user.

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

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

sudo systemctl daemon-reload

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

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

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

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

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

Когда вы маскируете службу, 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

Вывод должен показать 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".

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

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.