Как автоматически запускать службы при загрузке в RHEL / CentOS 7?

Хотите знать, как управлять услугами в фоновом режиме или при загрузке?


Механизм управления и запуска процессов при загрузке был изменен. До RHEL / CentOS 6.x вы бы создали скрипт в /etc/init.d/ и включили его с помощью chkconfig, но на RHEL 7.

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

Что такое systemd?

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

~ $ ps -ef | grep systemd
root 1 0 0 Nov11? 00:01:02 / lib / systemd / systemd –system –deserialize 22
сообщение + 768 10 ноября 11? 00:05:46 / usr / bin / dbus-daemon –system –address = systemd: –nofork –nopidfile –systemd-активация –syslog-only
root 805 1 0 ноя11? 00:10:22 / lib / systemd / systemd-logind
ankush 1132 10 ноября 11? 00:00:00 / lib / systemd / systemd –user
анкуш 1176 1132 0 ноя11? 00:04:50 / usr / bin / dbus-daemon –session –address = systemd: –nofork –nopidfile –systemd-активация –syslog-only
ankush 9772 20029 0 21:11 баллов / 6 00:00:00 grep –color = auto systemd
systemd + 17298 10 ноября 19? 00:00:12 / lib / systemd / systemd-resolved
systemd + 17303 10 ноября 19? 00:00:00 / lib / systemd / systemd-timesyncd
root 17307 1 0 ноя19? 00:00:02 / lib / systemd / systemd-journald
корень 18182 1 ноября 19? 00:00:00 / lib / systemd / systemd-udevd

Могу поспорить, вы заметили это мгновенно. первый процесс в списке был запущен от имени пользователя root и имеет pid 1.

Конечно же, это был первый процесс, который система запустила при загрузке. Передай привет systemd. ��

Итак, довольно просто, systemd – это «материнский» процесс, который запускает, управляет и завершает другие процессы в системе, помимо предоставления информации об их журналировании, статусах файловой системы и т. Д..

Заметка на имя, хотя. Название действительно systemd, а не System D или что-то еще. «D» обозначает демон, стандартный процесс Linux, который работает (скрывается?) В фоновом режиме и не привязан ни к одному терминальному сеансу.

Почему RHEL перешел на systemd?

Как мы уже обсуждали, systemd является менеджером системы и процессов и в RHEL 7 заменяет известную программу Upstart. Почему RHEL (Oracle?) Принял это решение? Ну, для этого есть очень веские причины, поэтому давайте взглянем.

Параллельная инициализация сервиса

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

Динамическое (горячее) управление сервисом

Если вы заметили, что USB-накопители должны быть явно смонтированы в более ранних системах Fedora, в то время как они автоматически открываются в Ubuntu и аналогичных дистрибутивах, причина в systemd. Он способен обнаруживать живые изменения в оборудовании и завершать / запускать службы по мере необходимости. Некоторые могут утверждать, что это ненужно, но для многих приветствуется все, что уменьшает когнитивное бремя..

Отложенный запуск сервиса

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

Быстрее процесс общения

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

Автоматический перезапуск

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

В любом случае, systemd облегчает жизнь сисадмина.

systemd в RHEL7 – что меняется для сисадминов?

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

Ограниченная поддержка на уровне выполнения

systemd имеет довольно потрепанное распознавание и поддержку уровней запуска. Не все уровни выполнения поддерживаются, и для некоторых целей их может даже не быть. В таких случаях systemd возвращает «N» в ответ на команды уровня запуска, что означает, что он не имеет соответствующего уровня выполнения для этой цели. В общем, Red Hat советует нам не использовать (!) Команды уровня запуска.

Нет пользовательских команд

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

Только для семьи и неинтерактивный

systemd (конечно) отслеживает запущенные процессы и сохраняет их PID. Проблема, однако, заключается в том, что systemd не может работать с процессами, не запущенными им. Кроме того, пользователь не может взаимодействовать с процессом, запущенным systemd. Все выходные данные отправляются в / dev / null, эффективно останавливая любые надежды на получение выходных данных..

Нет контекста

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

Если этот список ограничений заставляет вас плакать, опять же, вы не одиноки. systemd был поляризующей силой в мире Linux, и поиск в Google по запросу «systemd sucks» найдет множество материалов для чтения. ��

Как запустить сервис автоматически при выключении?

Вот довольно распространенный вариант использования при развертывании. Нам нужно демонизировать программу на языке, который не имеет долго выполняющихся процессов: PHP! Давайте предположим, что я пишу PHP-скрипт для обработки входящих подключений через веб-сокеты (в конце концов, мы создали приложение для чата!), И сценарий размещен в /home/ankush/chat_server/index.php.

Поскольку соединения через веб-сокет могут попасть на сервер в любое время, этот процесс должен постоянно выполняться и контролировать входящие соединения. У нас не может быть традиционного жизненного цикла PHP здесь, потому что WebSockets – это соединения с отслеживанием состояния, и если сценарий умирает, соединение представляет собой список. Во всяком случае, достаточно на веб-сокеты; Давайте посмотрим, как мы будем демонизировать этот скрипт через systemd..

Все системные сервисы находятся в / etc / systemd / system, поэтому давайте создадим там файл для описания нашего скрипта сервера websocket. Предполагая, что вы вошли в систему как пользователь root.

# vi /etc/systemd/system/chat_server.service

а затем необходимо следующее.

[Единица измерения]
Описание = Служба чата
После того, как = network.target

[Обслуживание]
Тип = простой
Пользователь = Ankush
ExecStart = php /home/ankush/chat_server/index.php
Restart = на прерывании

[Установить]
WantedBy = multi-user.target

Сохраните файл, и следующий шаг – перезагрузить демон systemd.

# systemctl daemon-reload

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

# systemctl start chat_server

Если вы не видите ошибок, это было!

Давайте также быстро посмотрим, что означают различные директивы в файле:

  • Часть [Unit] определяет новый сервисный модуль для systemd. На языке systemd все сервисы известны как сервисные единицы.
  • Директива After (как и ожидалось) указывает systemd запускать эту службу только после запуска сетевых служб (в противном случае, кто будет выполнять низкоуровневую обработку соединений с сокетами ?!).
  • Type = simple сообщает systemd, что этот сервис не должен сам форкаться. Другими словами, только один экземпляр будет запущен в любой момент времени..
  • Пользователь = ankush означает, что этот сервис будет работать как пользователь «ankush». Мы могли бы изменить это на «root», но это крайне не рекомендуется с точки зрения безопасности.
  • ExecStart, как вы можете сказать, является фактической командой для запуска.
  • Restart = on-abort означает, что служба должна быть перезапущена, когда она прерывается. В PHP долго выполняющиеся процессы теряют память и в конечном итоге взрываются, так что это необходимо.
  • Директива WantedBy = сообщает systemd, к какой цели (представьте группы) этот сервис относится. Это приводит к тому, что внутри этой цели создаются символические ссылки, указывающие на сервис.

Как правило, этого достаточно для запуска фоновых процессов с использованием systemd в RHEL 7.

Больше параметров для логики перезапуска

В приведенном выше примере я настроил Restart = on-abort, но это не единственный вариант. Есть еще и выбирайте исходя из требований.

  • на провал – будет перезапущен, когда нечистый код выхода или сигнал
  • всегда – перезапустить, если обнаружен неработающий, чистый или нечистый сигнал
  • на ненормальное – нечистый сигнал, сторож или тайм-аут
  • на успех – только когда он был остановлен чистым сигналом или кодом выхода

Настройка службы для запуска при загрузке

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

Перейдите в / etc / systemd / system и выполните приведенную ниже команду enable (не забудьте изменить имя файла .service на то, которое у вас есть)

# systemctl enable chat_server.service

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

Создана символическая ссылка от /etc/systemd/system/multi-user.target.wants/chat_server.service на /etc/systemd/system/chat_server.service.

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

Это было легко! Разве это не?

Помогите! Я вкладываю огромные средства в Upstart. ��

Я понимаю, что вы мне доверяете, ваш случай является скорее нормой, чем исключением. RHEL использует Upstart так долго, что переключение кажется почти предательством. Но эй, системы постоянно меняются, и мы не должны ссориться из-за пустяков. Red Hat признает, что многие люди застряли на старых версиях и создали руководство по миграции что вы должны обязательно обратиться к.

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

Хотите узнать больше об администрировании и устранении неполадок в Linux? Проверьте это онлайн курс.

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me
    Like this post? Please share to your friends:
    Adblock
    detector
    map