Как настроить службу Linux для автоматического запуска после сбоя или перезагрузки — часть 1: практические примеры

Автор выбрал программу Write for DOnations.

Введение

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

В первой части рассматриваются общие концепции управления службами Linux, такие как демон init и уровни выполнения. Он заканчивается демонстрацией управления службами в systemd. Здесь вы изучите файлы targets, wants, requires и unit.

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

Примечание. Вы также можете прочитать наше очень популярное руководство по использованию systemctl для управления службами и модулями systemd.

Предпосылки

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

• Сервер под управлением CentOS 8, включая пользователя без полномочий root с привилегиями sudo. Чтобы настроить все это, включая брандмауэр, вы можете обратиться к Руководству по начальной настройке сервера.

Знакомство с демоном управления службами

Службы Linux можно сделать самовосстанавливающимися, в основном, изменив способ их обработки демоном управления службами, также известным как демон init.

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

По мере развития Linux менялось и поведение демона init. Первоначально Linux начинался с System V init, той же самой, что использовалась в Unix. С тех пор в Linux был реализован демон Upstart init (созданный Ubuntu), а теперь демон systemd init (впервые реализованный Fedora).

Большинство современных дистрибутивов Linux постепенно отходят от System V и в настоящее время используют systemd. Старый стиль init (если используется) сохраняется только для обратной совместимости. FreeBSD, вариант UNIX, использует другую реализацию System V, известную как BSD init.

В этой статье мы рассмотрим systemd, так как это самый последний и распространенный диспетчер служб, который сегодня используется в дистрибутивах Linux. Тем не менее, мы также будем говорить о System V и Upstart, когда это будет необходимо, и посмотрим, как оттуда развился systemd. Чтобы дать вам представление:

• System V — старейшая система init, использовавшаяся в
• Debian 6 и более ранние версии
• Ubuntu 9.04 и более ранние версии
• CentOS 5 и более ранние версии
• Upstart появился после System V и использовался в
• От Ubuntu 9.10 до Ubuntu 14.10, включая Ubuntu 14.04
• ЦентрОС 6
• systemd — новейший менеджер служб Linux, используемый в
• Debian 7 и выше
• Ubuntu 15.04 и выше
• CentOS 7 и выше

Чтобы понять демона init, давайте начнем с того, что называется уровнем выполнения.

Уровни выполнения

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

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

• Уровень запуска 0: завершение работы системы
• Уровень запуска 1: однопользовательский, аварийный режим
• Уровни запуска 2, 3, 4: многопользовательский, текстовый режим с поддержкой сети
• Уровень выполнения 5: многопользовательский, сетевой, графический режим.
• Уровень выполнения 6: перезагрузка системы

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

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

Знакомство с демоном инициализации System V

System V использует файл inittab, который более поздние методы init сохранили для обратной совместимости. Давайте пробежимся по последовательности запуска System V:

1. Демон init создается из двоичного файла /sbin/init
2. Первый файл, который читает демон init, это /etc/inittab
3. Одна из записей в этом файле определяет уровень выполнения, с которого должна загружаться машина. Например, если значение для уровня выполнения указано как 3, Linux будет загружаться в многопользовательском текстовом режиме с включенной сетью. (Этот уровень выполнения называется уровнем запуска по умолчанию)
4. Затем демон init просматривает файл /etc/inittab и читает, какие сценарии init ему нужно запустить для данного уровня запуска

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

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

Когда процесс или служба, такая как MySQL Server, запускается под System V, его двоичный программный файл должен загружаться в память. В зависимости от того, как настроена служба, эта программа может непрерывно выполняться в фоновом режиме (и принимать клиентские подключения). Работа по запуску, остановке или перезагрузке этого бинарного приложения обрабатывается скриптом службы init. Он называется сценарием init, потому что он инициализирует службу.

В System V сценарий init является сценарием оболочки. Их также называют сценариями rc (команда запуска). Сценарии находятся в каталоге /etc/init.d. Эти скрипты имеют символические ссылки на каталоги /etc/rc. В каталоге /etc есть несколько каталогов rc, каждый из которых имеет номер в своем имени. Цифры обозначают разные уровни выполнения. Итак, у нас есть /etc/rc0.d, /etc/rc1.d, /etc/rc2.d и так далее.

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

ms:2345:respawn:/bin/sh /usr/bin/service_name

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

sudo chkconfig service_name on

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

sudo chkconfig service_name off

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

sudo service service_name status

Знакомство с демоном Upstart

Поскольку сериализованный способ загрузки заданий и служб стал более трудоемким и сложным с System V init, был введен демон Upstart для более быстрой загрузки ОС, изящной очистки аварийных служб и предсказуемой зависимости. между системными службами.

Upstart init был лучше, чем System V init по нескольким причинам:

• Для загрузки служб и управления ими не использовались тайные сценарии оболочки. Вместо этого он использует простые файлы конфигурации, которые легко понять и изменить.
• Службы не загружались последовательно, как System V, что сокращает время загрузки системы.
• Использовалась гибкая система событий для настройки обработки служб в различных состояниях.
• У Upstart были лучшие способы обработки того, как аварийный сервис должен восстановиться.
• Не было необходимости хранить несколько избыточных символических ссылок, указывающих на один и тот же скрипт

Для простоты Upstart обратно совместим с System V. Сценарий /etc/init.d/rc по-прежнему работает для управления собственными службами System V. Его основное отличие заключается в том, что он позволяет связать несколько событий со службой. Эта основанная на событиях архитектура позволила Upstart быть гибким менеджером услуг. С Upstart каждое событие может запустить сценарий оболочки, который позаботится об этом событии. Эти события включали:

• Запуск
• Начато
• Остановка
• Остановлено

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

При запуске Upstart будет запускать любые сценарии System V init в обычном режиме. Затем он просматривает каталог /etc/init и выполняет команды оболочки в каждом файле конфигурации службы. Помимо прочего, эти файлы контролировали поведение службы при запуске.

Файлы имеют стиль именования service_name.conf и содержат обычный текст с различными разделами, называемыми строфами. Каждая строфа описывает отдельный аспект службы и ее поведение. Чтобы служба запускалась автоматически после сбоя или перезагрузки, вы можете добавить команду respawn в ее файлы конфигурации службы, как показано ниже для службы cron.

...

description "regular background program processing daemon"

start on runlevel [2345]

stop on runlevel [!2345]

expect fork

**respawn**

exec cron

Знакомство с демоном systemd

Последним демоном init в Linux является systemd. На самом деле это больше, чем демон init: systemd — это фреймворк, который включает в себя многие компоненты современной системы Linux.

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

systemd обратно совместим с командами System V и сценариями инициализации. Это означает, что любая служба System V также будет работать под управлением systemd. Это возможно, потому что большинство административных команд Upstart и System V были изменены для работы в systemd.

Файлы конфигурации systemd: файлы модулей

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

Основное различие между systemd и двумя другими методами init заключается в том, что systemd отвечает за инициализацию сервисных демонов и других типов ресурсов, таких как пути операционной системы устройства, точки монтирования, сокеты и т. д. Стиль именования для файла модуля — service_name.unit_type. Итак, вы увидите такие файлы, как dbus.service, sshd.socket или home.mount.

Структура каталогов

В системах на основе Red Hat, таких как CentOS, файлы модулей расположены в двух местах. Основное расположение — /lib/systemd/system/. Пользовательские файлы модулей или существующие файлы модулей, измененные системными администраторами, будут находиться в папке /etc/systemd/system.

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

Последовательность инициализации systemd: Целевые единицы

Особым типом файла модуля является целевой модуль.

Имя файла целевого модуля имеет суффикс .target. Целевые единицы отличаются от других файлов единиц, поскольку они не представляют один конкретный ресурс. Скорее, они представляют состояние системы в любой момент времени. Целевые модули делают это, группируя и запуская несколько файлов модулей, которые должны быть частью этого состояния. Таким образом, цели systemd можно приблизительно сравнить с уровнями выполнения System V, хотя они и не совпадают.

У каждой цели есть имя, а не номер. Например, у нас есть multi-user.target вместо runlevel 3 или reboot.target вместо runlevel 6. . Когда сервер Linux загружается, скажем, с multi-user.target, он, по сути, переводит сервер на уровень запуска 2, 3 или 4, что является многопользовательским текстовым режимом. с включенной сетью.

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

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

Например, в системе Linux, которая загружается с графическим пользовательским интерфейсом, будет активирован graphical.target, что, в свою очередь, автоматически обеспечит загрузку и активацию multi-user.target. В терминах System V это было бы похоже на одновременную активацию уровней выполнения 3 и 5.

В таблице ниже сравниваются уровни запуска и цели:

systemd default.target

systemd default.target эквивалентен уровню запуска System V по умолчанию.

В System V уровень запуска по умолчанию был определен в файле inittab. В systemd этот файл заменяется на default.target. Файл целевого модуля по умолчанию находится в каталоге /etc/systemd/system. Это символическая ссылка на один из целевых файлов модулей в /lib/systemd/system.

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

Файл inittab в System V также указывает, из какого каталога Linux будет выполнять свои сценарии init: это может быть любой из каталогов rcn.d. В systemd целевая единица по умолчанию определяет, какие единицы ресурсов будут загружены во время загрузки.

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

Зависимости systemd: хочет и требует

systemd хочет и требует контроля над тем, как systemd обращается к зависимостям между сервисными демонами.

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

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

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

Практический пример: понимание последовательности запуска systemd

Чтобы понять поведение запуска службы в systemd, мы используем каплю CentOS 8.3. Мы будем следовать по кроличьей тропе .target насколько это возможно. Последовательность запуска systemd следует длинной цепочке зависимостей.

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

sudo ls -l /etc/systemd/system/default.target

Это показывает вывод, как показано ниже:

Output
lrwxrwxrwx. 1 root root 37 Dec  4 17:42 /etc/systemd/system/default.target -> /lib/systemd/system/multi-user.target

Как видите, цель по умолчанию на самом деле является символической ссылкой на многопользовательский целевой файл в папке /lib/systemd/system/. Таким образом, предполагается, что система загружается под multi-user.target, что аналогично уровню запуска 3 в System V init.

многопользовательская.цель.хочет

Затем давайте запустим следующую команду, чтобы проверить все службы, которые нужны файлу multi-user.target:

sudo ls -l /etc/systemd/system/multi-user.target.wants/*.service

Это должно показать список файлов символических ссылок, указывающих на фактические файлы модулей в /usr/lib/systemd/system/:

Output
lrwxrwxrwx. 1 root root 38 Dec  4 17:38 /etc/systemd/system/multi-user.target.wants/auditd.service -> /usr/lib/systemd/system/auditd.service
lrwxrwxrwx. 1 root root 39 Dec  4 17:39 /etc/systemd/system/multi-user.target.wants/chronyd.service -> /usr/lib/systemd/system/chronyd.service
lrwxrwxrwx. 1 root root 37 Dec  4 17:38 /etc/systemd/system/multi-user.target.wants/crond.service -> /usr/lib/systemd/system/crond.service
lrwxrwxrwx. 1 root root 42 Dec  4 17:39 /etc/systemd/system/multi-user.target.wants/irqbalance.service -> /usr/lib/systemd/system/irqbalance.service
lrwxrwxrwx. 1 root root 37 Dec  4 17:41 /etc/systemd/system/multi-user.target.wants/kdump.service -> /usr/lib/systemd/system/kdump.service
...

Помимо multi-user.target, существуют другие типы целей, такие как system-update.target или basic.target. Чтобы увидеть, от каких целей зависит многопользовательская цель, выполните следующую команду:

sudo systemctl show --property "Requires" multi-user.target | fmt -10

Вывод показывает:

Output
Requires=basic.target

базовая.цель

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

sudo systemctl show --property "Requires" basic.target | fmt -10

Как оказалось, для basic.target требуется sysinit.target:

Output
Requires=sysinit.target
-.mount

И он также хочет несколько целей:

sudo systemctl show --property "Wants" basic.target | fmt -10

Команда вернет следующее:

Output
Wants=slices.target
paths.target
timers.target
microcode.service
sockets.target
sysinit.target

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

sudo systemctl show --property "Requires" sysinit.target | fmt -10

Их не будет. Однако для sysinit.target будут нужны и другие цели:

systemctl show --property "Wants" sysinit.target | fmt -10

Появится такой вывод:

Output
Wants=systemd-random-seed.service
dev-mqueue.mount
rngd.service
systemd-modules-load.service
proc-sys-fs-binfmt_misc.automount
local-fs.target
sys-fs-fuse-connections.mount
systemd-sysusers.service
systemd-update-done.service
systemd-update-utmp.service
systemd-journal-flush.service
dev-hugepages.mount
dracut-shutdown.service
swap.target
systemd-udevd.service
import-state.service
sys-kernel-debug.mount
nis-domainname.service
systemd-journald.service
selinux-autorelabel-mark.service
kmod-static-nodes.service
loadmodules.service
ldconfig.service
cryptsetup.target
systemd-sysctl.service
systemd-ask-password-console.path
systemd-journal-catalog-update.service
systemd-udev-trigger.service
systemd-tmpfiles-setup.service
systemd-hwdb-update.service
sys-kernel-config.mount
systemd-binfmt.service
systemd-tmpfiles-setup-dev.service
systemd-machine-id-commit.service
systemd-firstboot.service

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

Сделав еще один шаг, давайте заглянем в файл сервисного модуля, тот, что для sshd:

sudo vi /etc/systemd/system/multi-user.target.wants/sshd.service

Это выглядит так:

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

[Service]
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

[Install]
WantedBy=multi-user.target

Вы можете видеть, что файл сервисной единицы чист и понятен.

Первой важной частью является предложение After в разделе [Unit]. Это говорит о том, что служба sshd должна загружаться после загрузки network.target и sshd-keygen.target.

Раздел [Install] показывает, что служба нужна multi-user.target. Это означает, что multi-user.target загрузит демон sshd, но не выключится и не рухнет, если sshd выйдет из строя во время загрузки.

Поскольку multi-user.target является целью по умолчанию, демон sshd должен запускаться во время загрузки. В разделе [Service] параметр Restart имеет значение при сбое. Этот параметр позволяет перезапускать демон sshd в случае его сбоя или некорректного выхода.

Заключение

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

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