TOC

Как настроить службу Linux для автоматического запуска после сбоя или перезагрузки - Часть 2. Справочник

Вступление

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

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

Мы увидели, как это сделать в трех разных режимахinit: System V, Upstart и systemd. Прочтитеfirst tutorial, чтобы узнать, какие дистрибутивы используют какую систему инициализации по умолчанию.

В этом уроке мы сделаем шаг назад и объясним, почему мы выполнили команды и отредактировали файлы конфигурации, которые мы сделали. Начнем с демона инициализации System V. Мы также увидим, почему со временем его заменили на новые режимы инициализации.

Предпосылки

Чтобы следовать этому руководству, вам потребуются три капли DigitalOcean, которые вы создалиbefore.

У нас были:

  • Сервер Debian 6 под управлением MySQL

  • Сервер Ubuntu 14.04 под управлением MySQL

  • Сервер CentOS 7 под управлением MySQL

Мы рекомендуем вам вернуться к первой части этой серии и сначала создать капли.

Также вам необходимо быть пользователем root или иметь права sudo на серверах. Чтобы понять, как работают привилегии sudo, см.this DigitalOcean tutorial about sudo.

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

Уровни

runlevel представляет текущее состояние системы Linux.

Концепция исходит от System V init, где система Linux загружается, инициализирует ядро, а затем вводит один (и только один) уровень выполнения.

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

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

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

  • Runlevel 0: Завершение работы системы

  • Runlevel 1: Однопользовательский, режим восстановления

  • Runlevels 2, 3, 4: Многопользовательский текстовый режим с включенной сетью

  • Runlevel 5: Многопользовательский, с подключением к сети, графический режим

  • Runlevel 6: Перезагрузка системы

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

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

Уровни выполнения становятсяtargets в systemd, что мы обсудим в разделе systemd.

Init и PID 1

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

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

Каждый процесс в Linux имеет идентификатор процесса (PID), аinit имеет PID 1. Это родитель всех других процессов, которые впоследствии появляются, когда система подключается к сети.

История Init

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

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

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

System V Init Sequence

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

Давайте пройдемся по последовательности запуска System V:

  1. Демон инициализации создается из двоичного файла/sbin/init

  2. Первый файл, который читает демон инициализации, - это/etc/inittab

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

  4. Затем демон init просматривает файл/etc/inittab и считывает, какиеinit scripts ему нужно запустить для этого уровня запуска.

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

Далее давайте рассмотрим сценарии инициализации более подробно.

Конфигурационные файлы System V: сценарии инициализации

Сценарий инициализации - это то, что управляет конкретной службой, такой как MySQL Server, в системе V.

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

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

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

В System V сценарий инициализации является сценарием оболочки.

Сценарии инициализации также называются сценариямиrc (команда запуска).

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

Каталог/etc является родительским каталогом для сценариев инициализации.

Фактическое расположение сценариев оболочки инициализации находится в/etc/init.d. Эти сценарии связаны с каталогамиrc.

В каталоге/etc у нас есть несколько каталоговrc, каждый из которых имеет номер в имени.

Числа представляют разные уровни выполнения. Итак, у нас есть/etc/rc0.d,/etc/rc1.d,/etc/rc2.d и так далее.

Затем в каждом каталогеrcn.d есть файлы, которые начинаются сK илиS в имени файла, за которым следуют две цифры. Это файлы символьных ссылок, которые указывают на фактические сценарии оболочки init. ПочемуK иS? К означает Убить (т.е. остановка) и «S» означает «Старт».

Две цифры представляют порядок выполнения скрипта. Итак, если у нас есть файл с именем K25some_script, он будет выполняться до K99another_script.

Запускать

Давайте вернемся к нашей последовательности запуска. Так как же называются сценарии инициализации? Кто их называет?

Сценарии K и S вызываются не напрямую демоном инициализации, а другим сценарием: сценарием/etc/init.d/rc.

Если вы помните, файл/etc/inittab сообщает демону инициализации, на какой уровень запуска система должна перейти по умолчанию. Для каждого уровня выполнения строка в файле/etc/inittab вызывает сценарий/etc/init.d/rc, передавая этот уровень выполнения в качестве параметра. На основе этого параметра сценарий затем вызывает файлы в соответствующем каталоге/etc/rcn.d. Итак, если сервер загружается с уровнем запуска 2, будут вызываться сценарии под/etc/rc2.d; для уровня запуска 3 выполняются сценарии под/etc/rc3.d и так далее.

В каталогеrc сначала все сценарии K запускаются в числовом порядке с аргументом «stop», а затем все сценарии S запускаются аналогичным образом с аргументом «start». За кулисами будут вызываться соответствующие сценарии оболочки инициализации с параметрами остановки и запуска соответственно.

Теперь, поскольку файлы в каталогах/etc/rcn.d (файлыKnn иSnn) являются только символическими ссылками, их вызов означает вызов реальных сценариев оболочки инициализации с параметрами остановки и запуска.

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

[.Примечание]##

Этот вызов сценариев инициализации также происходит всякий раз, когда система переключается на новый уровень выполнения: выполняются соответствующие сценарии каталога/etc/rc<n>.d. И поскольку эти файлы K и S представляют собой не что иное, как ссылки, фактические сценарии оболочки в каталоге/etc/init.d выполняются с соответствующим аргументом запуска или остановки.

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

Система V Автозапуск

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

Так, например, когда мы включаем автоматический запуск службы на уровне запуска 3, за кулисами процесс создает соответствующие ссылки в каталоге/etc/rc3.d.

Если это звучит странно, не волнуйтесь - через минуту мы увидим, что все это значит.

Пример системы V

Мы вернемся к нашему примеру сервиса MySQL, на этот раз с большей теорией.

[[step-1 -—- logging-in-to-debian-droplet]] === Шаг 1 - Вход в Debian Droplet

Для целей этой части руководства мы вернемся к дроплету Debian 6, который мы создали в первой части. Используйте команду SSH для подключения к серверу (пользователи Windows могут подключиться с помощью такого инструмента, как PuTTy). 

ssh sammy@your_server_ip

[[step-2 -—- looking-at-inittab]] === Шаг 2. Просмотр inittab

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

cat /etc/inittab | grep initdefault

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

Outputid:2:initdefault:

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

cat /etc/inittab | grep Runlevel

вывод подтверждает это: 

Output# Runlevel 0 is halt.
# Runlevel 1 is single-user.
# Runlevels 2-5 are multi-user.
# Runlevel 6 is reboot.

[[step-3 -—- looking-at-the-rc-каталогов]] === Шаг 3 - Просмотр RC-каталогов

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

ls -ld /etc/rc*.d
Outputdrwxr-xr-x 2 root root 4096 Jul 31 07:09 /etc/rc0.d
drwxr-xr-x 2 root root 4096 Jul 31 07:09 /etc/rc1.d
drwxr-xr-x 2 root root 4096 Jul 31 07:21 /etc/rc2.d
drwxr-xr-x 2 root root 4096 Jul 31 07:21 /etc/rc3.d
drwxr-xr-x 2 root root 4096 Jul 31 07:21 /etc/rc4.d
drwxr-xr-x 2 root root 4096 Jul 31 07:21 /etc/rc5.d
drwxr-xr-x 2 root root 4096 Jul 31 07:09 /etc/rc6.d
drwxr-xr-x 2 root root 4096 Jul 23  2012 /etc/rcS.d

Поскольку система загружается на уровне запуска 2 (инициализация по умолчанию из файла inittab), сценарии в каталоге/etc/rc2.d будут выполняться при запуске системы.

Перечислите содержимое этого каталога: 

ls -l /etc/rc2.d

Это показывает, что файлы представляют собой не что иное, как символические ссылки, каждая из которых указывает на файлы скрипта в /etc/init.d: 

Output. . .
lrwxrwxrwx 1 root root  17 Jul 23  2012 S01rsyslog -> ../init.d/rsyslog
lrwxrwxrwx 1 root root  22 Jul 23  2012 S02acpi-support -> ../init.d/acpi-support
lrwxrwxrwx 1 root root  15 Jul 23  2012 S02acpid -> ../init.d/acpid
lrwxrwxrwx 1 root root  17 Jul 23  2012 S02anacron -> ../init.d/anacron
lrwxrwxrwx 1 root root  13 Jul 23  2012 S02atd -> ../init.d/atd
lrwxrwxrwx 1 root root  14 Jul 23  2012 S02cron -> ../init.d/cron
lrwxrwxrwx 1 root root  15 Jul 31 07:09 S02mysql -> ../init.d/mysql
lrwxrwxrwx 1 root root  13 Jul 23  2012 S02ssh -> ../init.d/ssh
. . .

Мы видим, что здесь нет K скриптов, только S (стартовые) скрипты. Скрипты запускают известные службы, такие какrsyslog,cron илиssh.

Помните, что две цифры после S определяют порядок запуска: например, rsyslog запускается перед демоном cron. Мы также можем видеть, что MySQL указан здесь.

[[step-4 -—- looking-at-an-init-script]] === Шаг 4 - Просмотр сценария инициализации

Теперь мы знаем, что при установке службы, совместимой с System V, она создает сценарий оболочки в каталоге/etc/init.d. Проверьте сценарий оболочки для MySQL: 

ls -l /etc/init.d/my*
Output-rwxr-xr-x 1 root root 5437 Jan 14  2014 /etc/init.d/mysql

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

cat /etc/init.d/mysql | less

Из вывода вы увидите, что это большой скрипт bash.

[[step-5 -—- using-chkconfig-or-sysv-rc-conf]] === Шаг 5. Использование chkconfig или sysv-rc-conf

В дистрибутивах на основе RHEL, таких как CentOS, команда под названиемchkconfig может использоваться для включения или отключения службы в System V. Он также может перечислить установленные службы и их уровни выполнения.

[.Примечание]##

Синтаксис для проверки состояния службы для всех уровней выполнения в системе CentOS: 

chkonfig --list | grep service_name

Такая утилита не поставляется с Debian изначально (update-rc.d устанавливает или удаляет службы только с уровней запуска). Однако мы можем установить специальный инструмент под названиемsysv-rc-conf, который поможет нам управлять услугами.

Выполните следующую команду для установкиsysv-rc-conf: 

sudo apt-get install sysv-rc-conf -y

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

sudo sysv-rc-conf

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

sysv-rc-conf Window showing X marks for various services for each runlevel

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

А пока выйдите из экрана, нажавQ.

[[step-7 -—- testing-mysql-startup-behavior-at-boot]] === Шаг 7 - Тестирование поведения MySQL при запуске при загрузке

Как вы можете видеть из скриншота в предыдущем разделе и из нашего тестирования в части 1 руководства, MySQL в настоящее время включен на уровнях выполнения 2-5.

Выполните следующую команду дляdisable службы MySQL: 

sudo update-rc.d mysql disable
Outputupdate-rc.d: using dependency based boot sequencing
insserv: warning: current start runlevel(s) (empty) of script `mysql' overwrites defaults (2 3 4 5).
insserv: warning: current stop runlevel(s) (0 1 2 3 4 5 6) of script `mysql' overwrites defaults (0 1 6).

Теперь запустите команду: 

ls -l /etc/rc2.d

Вывод должен показать, что символическая ссылка с/etc/rc2.d на/etc/init.d/mysql изменилась наK: 

Output. . .
lrwxrwxrwx 1 root root  15 Jul 31 07:09 K02mysql -> ../init.d/mysql
. . .

Другими словами, MySQL больше не будет запускаться с уровнем запуска по умолчанию (2).

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

Включите сервис снова: 

sudo update-rc.d mysql enable

[[шаг-8 -—- testing-mysql-start-up-behavior-on-crash]] === Шаг 8 - Тестирование поведения MySQL при запуске при сбое

Давайте посмотрим, как System V обрабатывает сбои службы.

Помните, что мы внесли изменения в файл/etc/inittab в части 1 этого руководства, чтобы MySQL запускался автоматически после сбоя. Мы добавили следующую строку:

/etc/inittab

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

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

sudo reboot

Как только сервер возвращается, подключитесь к нему по SSH и проверьте идентификаторы процессов MySQL, как раньше: 

ps -ef | grep mysql

Обратите внимание на идентификаторы процессов дляmysqld_safe иmysqld. В нашем случае это были 895 и 1019 соответственно: 

Outputroot       907     1  0 07:30 ?        00:00:00 /bin/sh /usr/bin/mysqld_safe
mysql     1031   907  0 07:30 ?        00:00:00 /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/run/mysqld/mysqld.sock --port=3306
root      1032   907  0 07:30 ?        00:00:00 logger -t mysqld -p daemon.error
root      2550  2532  0 07:31 pts/0    00:00:00 grep mysql

Снова завершите процессы с помощью переключателя-9 (замените идентификаторы PID на идентификаторы вашей системы Debian): 

sudo kill -9 907
sudo kill -9 1031

Подождите около пяти минут и затем выполните команду: 

sudo service mysql status

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

Output/usr/bin/mysqladmin  Ver 8.42 Distrib 5.1.73, for debian-linux-gnu on x86_64

Если вы снова запустите командуps -ef | grep mysql, вы увидите, что подошли процессыmysqld_safe иmysqld.

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

По этой причине мы добавили эту дополнительную строку в/etc/inittab: это то, как вы настраиваете службу System V для возрождения в случае сбоя. ВPart 1 есть подробное объяснение синтаксиса этой строки.

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

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

Выскочка Введение

Классический SysVinit был частью основных дистрибутивов Linux долгое время, пока не появился Upstart.

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

Необходимость в более быстрой загрузке ОС, постепенная очистка аварийных служб и предсказуемая зависимость между системными службами привели к необходимости лучшего менеджера служб. Разработчики в Ubuntu придумали еще один способ инициализации - демон Upstart.

Upstart init лучше System V в нескольких отношениях:

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

  • Upstart не загружает сервисы последовательно, как System V. Это сокращает время загрузки системы

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

  • У Upstart есть лучшие способы справиться с тем, как аварийный сервис должен возродиться

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

  • Upstart обратно совместим с системой V. Скрипт/etc/init.d/rc по-прежнему работает для управления собственными службами System V

События Upstart

Upstart позволяет связать несколькоeventsс сервисом. Эта основанная на событиях архитектура позволяет Upstart гибко относиться к управлению услугами.

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

События Upstart включают в себя:

  • начало

  • Началось

  • остановка

  • Остановился

Между этими событиями служба может находиться в количествеstates, например:

  • ожидание

  • предпусковой

  • начало

  • Бег

  • до остановки

  • остановка

  • etc.

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

Upstart Init Sequence

Как и System V, Upstart также запускает сценарий/etc/init.d/rc при запуске. Этот скрипт выполняет любые сценарии инициализации System V в обычном режиме.

Upstart также просматривает каталог/etc/init и выполняет команды оболочки в каждом файле конфигурации службы.

Файлы конфигурации Upstart

Upstart использует файлы конфигурации для управления сервисами.

Upstart не использует скрипты Bash, как System V. Вместо этого Upstart использует файлыservice configuration со стандартом именованияservice_name.conf.

Файлы имеют текстовое содержимое с разными разделами, называемымиstanzas. Каждая строфа описывает свой аспект службы и ее поведение.

Разные строфы управляют разными событиями для службы, напримерpre-start,start,pre-stop илиpost-stop.

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

Каждый файл конфигурации также определяет две вещи:

  • Какой уровень запуска должен запускаться и останавливаться

  • Должен ли сервисrespawn в случае сбоя

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

Файлы конфигурации Upstart находятся в каталоге/etc/init (не путать с/etc/init.d).

Пример выскочки

Давайте посмотрим, как Upstart снова работает с MySQL Server, на этот раз с дополнительными знаниями.

[[step-1 -—- logging-in-to-ubuntu-droplet]] === Шаг 1. Вход в Ubuntu Droplet

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

Используйте команду SSH для подключения к серверу (пользователи Windows могут подключиться с помощью такого инструмента, как PuTTy). 

ssh sammy@your_server_ip

[[step-2 -—- looking-at-the-init-and-rc-каталогов]] === Шаг 2. Просмотр каталогов init и rc

Большинство файлов конфигурации Upstart находится в каталоге/etc/init. Это каталог, который вы должны использовать при создании новых сервисов.

После входа на сервер выполните следующую команду: 

sudo ls -l /etc/init/ | less

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

Outputtotal 356
. . .
-rw-r--r-- 1 root root  297 Feb  9  2013 cron.conf
-rw-r--r-- 1 root root  489 Nov 11  2013 dbus.conf
-rw-r--r-- 1 root root  273 Nov 19  2010 dmesg.conf
. . .
-rw-r--r-- 1 root root 1770 Feb 19  2014 mysql.conf
-rw-r--r-- 1 root root 2493 Mar 20  2014 networking.conf

НажмитеQ, чтобы выйти изless.

Сравните это с собственными службами инициализации System V в системе: 

sudo ls -l /etc/rc3.d/* | less

Там будет только горстка 

Output-rw-r--r-- 1 root root 677 Jun 14 23:31 /etc/rc3.d/README
lrwxrwxrwx 1 root root  15 Apr 17  2014 /etc/rc3.d/S20rsync -> ../init.d/rsync
lrwxrwxrwx 1 root root  24 Apr 17  2014 /etc/rc3.d/S20screen-cleanup -> ../init.d/screen-cleanup
lrwxrwxrwx 1 root root  19 Apr 17  2014 /etc/rc3.d/S70dns-clean -> ../init.d/dns-clean
lrwxrwxrwx 1 root root  18 Apr 17  2014 /etc/rc3.d/S70pppd-dns -> ../init.d/pppd-dns
lrwxrwxrwx 1 root root  26 Apr 17  2014 /etc/rc3.d/S99digitalocean -> ../init.d//rc.digitalocean
lrwxrwxrwx 1 root root  21 Apr 17  2014 /etc/rc3.d/S99grub-common -> ../init.d/grub-common
lrwxrwxrwx 1 root root  18 Apr 17  2014 /etc/rc3.d/S99ondemand -> ../init.d/ondemand
lrwxrwxrwx 1 root root  18 Apr 17  2014 /etc/rc3.d/S99rc.local -> ../init.d/rc.local

[[step-3 -—- looking-at-an-upstart-file]] === Шаг 3 - Просмотр файла Upstart

Мы уже видели файлmysql.conf в Части 1 этого руководства. Итак, давайте откроем другой файл конфигурации: тот, что для демона cron. 

sudo nano /etc/init/cron.conf

Как видите, это довольно простой конфигурационный файл для демона cron:

/etc/init/cron.conf

# cron - regular background program processing daemon
#
# cron is a standard UNIX program that runs user-specified programs at
# periodic scheduled times

description     "regular background program processing daemon"

start on runlevel [2345]
stop on runlevel [!2345]

expect fork
respawn

exec cron

Здесь следует помнить о важных полях:start on,stop on иrespawn.

Директиваstart on указывает Ubuntu запускать демонcrond, когда система переходит на уровни выполнения 2, 3, 4 или 5. 2, 3 и 4 - многопользовательские текстовые режимы с включенной поддержкой сети, а 5 - многопользовательский графический режим. Служба не работает на других уровнях выполнения (например, 0,1 или 6).

Директиваfork сообщает Upstart, что процесс должен отключиться от консоли и работать в фоновом режиме.

Далее идет директиваrespawn. Это говорит системе, что cron должен запуститься автоматически, если по какой-либо причине происходит сбой.

Выйдите из редактора без внесения каких-либо изменений.

Конфигурационный файл cron - это довольно маленький файл конфигурации. Файл конфигурации MySQL структурно аналогичен файлу конфигурации cron; у него также есть строфы для старта, остановки и респауна. Кроме того, он также имеет два блока сценариев для событий до и после запуска. Эти блоки кода сообщают системе, что выполнять, когда процесс mysqld либо запускается, либо уже запущен.

Для практической помощи по созданию собственного файла Upstart см.this tutorial about Upstart.

[[step-4 -—- testing-mysql-startup-behavior-at-boot]] === Шаг 4 - Тестирование поведения MySQL при запуске при загрузке

Мы знаем, что экземпляр MySQL на нашем сервере Ubuntu 14.04 по умолчанию настроен на автоматический запуск во время загрузки. Давайте посмотрим, как мы можем отключить это.

В Upstart отключение службы зависит от наличия файла в/etc/init/ с именемservice_name.override. Содержимое файла должно быть простым словом:manual.

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

sudo nano /etc/init/mysql.override

Добавьте эту единственную строку:

/etc/init/mysql.override

manual

Сохраните ваши изменения.

Далее перезагрузите сервер: 

sudo reboot

Как только сервер вернется в онлайн, проверьте статус сервиса 

sudo initctl status mysql

Выход должен быть: 

Outputmysql stop/waiting

Это означает, что MySQL не запускался.

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

sudo cat /etc/init/mysql.conf | grep start\ on

Все должно быть так же: 

Outputstart on runlevel [2345]

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

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

sudo rm -f /etc/init/mysql.override
sudo reboot

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

Выполнение командыsudo initctl status mysql покажет, что служба запущена автоматически.

[[step-5 -—- testing-mysql-startup-behavior-on-crash]] === Шаг 5. Тестирование поведения при запуске MySQL при сбое

По умолчанию MySQL запускается автоматически после сбоя.

Чтобы остановить MySQL, откройте файл конфигурации службы/etc/init/mysql.conf: 

sudo nano /etc/init/mysql.conf

Закомментируйте обе директивыrespawn.

/etc/init/mysql.conf

# respawn
# respawn limit 2 5

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

sudo initctl stop mysql
sudo initctl start mysql

Мы явно останавливаем и запускаем службу, потому что наш тест показал, чтоinitctl restart илиinitctl reload здесь не работают.

Вторая команда для запуска службы показывает PID MySQL, запущенный с: 

Outputmysql start/running, process 1274

Обратите внимание на PID для вашего экземпляра MySQL. Если вы сейчас остановите процессmysql, он не появится автоматически. Завершите процесс OF (заменив его своим собственным номером): 

sudo kill -9 1274

Теперь проверьте его статус: 

sudo initctl status mysql
Outputmysql stop/waiting

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

Part 1 руководства содержит более подробное объяснение директивrespawn.

[.Примечание]##

Когда вы,not, хотите, чтобы служба Upstart запускалась после перезагрузки или сбоя?

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

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

Введение в systemd

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

Одна из его функций - работать какsystem and service manager для Linux. В этом качестве systemd управляет тем, как должен вести себя сервис в случае сбоя или перезагрузки компьютера. Вы можете прочитать проsystemd’s systemctl here.

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

Фактически, если мы запустим командуps -ef | grep systemd в операционной системе, которая ее поддерживает, мы ничего не увидим, потому чтоsystemd переименовывается вinit во время загрузки. Существует файл/sbin/init, который представляет собой символическую ссылку на/bin/systemd.

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

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

Информация о ресурсе отслеживается в файле модуля.

Каждый файл модуля представляет определенный системный ресурс и имеет стиль именованияservice name.unit type.

Итак, у нас будут файлы типаdbus.service,sshd.socket илиhome.mount.

Как мы увидим позже, файлы служебных модулей - это простые текстовые файлы (например, файлы Upstart.conf) с декларативным синтаксисом. Эти файлы довольно легко понять и изменить.

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

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

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

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

Начальная последовательность systemd: целевые единицы

Особый тип файла модуля - этоtarget unit.

Имя файла целевого устройства имеет суффикс.target. Целевые единицы отличаются от других файлов единиц, потому что они не представляют один конкретный ресурс. Скорее, они представляют состояние системы в любое время.

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

У каждой цели есть имя вместо номера. Например, у нас естьmulti-user.target вместо уровня выполнения 3 илиreboot.target вместо уровня выполнения 6.

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

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

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

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

(В терминах System V это будет похоже на одновременную активацию уровней запуска 3 и 5.)

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

Уровень выполнения (System V init) Целевые единицы (Systemd)

уровень выполнения 0

poweroff.target

уровень выполнения 1

resuce.target

уровень выполнения 2, 3, 4

multi-user.target

уровень выполнения 5

graphical.target

уровень выполнения 6

reboot.target

systemd default.target

default.target эквивалентен уровню выполнения по умолчанию.

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

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

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

Все эти устройства активированы, но не все параллельно или все последовательно. Способ загрузки единицы ресурса может зависеть от других единиц ресурса этоwants илиrequires.

Системные зависимости: хочет и требует

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

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

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

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

Пример systemd

Настало время глубоко погрузиться в поведение при запуске MySQL в systemd.

[[step-1 -—- log-in-to-centos-droplet]] === Шаг 1 - Войдите в CentOS Droplet

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

Используйте команду SSH для подключения к серверу (пользователи Windows могут подключиться с помощью такого инструмента, как PuTTy). 

ssh sammy@your_server_ip

[[step-2 -—- looking-at-default-target-file-and-dependencies]] === Шаг 2 - Просмотр файла default.target и зависимостей

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

defaul.target

Файлdefault.target определяет, какие службы запускаются во время нормальной загрузки сервера.

Выполните следующую команду, чтобы получить список целевых файлов по умолчанию: 

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

Это показывает вывод как следующее: 

Outputlrwxrwxrwx. 1 root root 37 Jul  8  2014 /etc/systemd/system/default.target -> /lib/systemd/system/multi-user.target

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

multi-user.target.wants

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

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

Это должно показать вывод как это: 

Output. . .
lrwxrwxrwx. 1 root root  37 Jul  8  2014 /etc/systemd/system/multi-user.target.wants/crond.service -> /usr/lib/systemd/system/crond.service
. . .
lrwxrwxrwx  1 root root  38 Jul 31 22:02 /etc/systemd/system/multi-user.target.wants/mysqld.service -> /usr/lib/systemd/system/mysqld.service
lrwxrwxrwx. 1 root root  46 Jul  8  2014 /etc/systemd/system/multi-user.target.wants/NetworkManager.service -> /usr/lib/systemd/system/NetworkManager.service
lrwxrwxrwx. 1 root root  39 Jul  8  2014 /etc/systemd/system/multi-user.target.wants/postfix.service -> /usr/lib/systemd/system/postfix.service
lrwxrwxrwx. 1 root root  39 Jul  8  2014 /etc/systemd/system/multi-user.target.wants/rsyslog.service -> /usr/lib/systemd/system/rsyslog.service
lrwxrwxrwx. 1 root root  36 Jul  8  2014 /etc/systemd/system/multi-user.target.wants/sshd.service -> /usr/lib/systemd/system/sshd.service
. . .

Мы видим, что это все файлы символьных ссылок, указывающие на фактические файлы модулей в/lib/systemd/system/. Мы также можем видеть, чтоmysqld.service является частьюmulti-user.target.

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

sudo systemctl show --property "Wants" multi-user.target | fmt -10 | grep mysql
Outputmysqld.service

Помимоmulti-user.target, существуют различные типы целей, напримерsystem-update.target илиbasic.target.

Чтобы увидеть, от каких целей зависит наша многопользовательская цель, выполните следующую команду: 

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

Таким образом, чтобы запустить систему в режимеmulti-user.target, сначала необходимо загрузитьbasic.target.

basic.target

Чтобы увидеть, от каких других целей зависитbasic.target, выполните эту команду: 

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

Выход будет: 

OutputRequires=sysinit.target

sysinit.target

Идя рекурсивно, мы можем увидеть, есть ли требуемые единицы дляsysinit.target. Там нет ни одного. Однако мы можем увидеть, какие услугиwanted поsysinit.target: 

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

Это покажет ряд услуг, которые хочет sysinit. 

OutputWants=local-fs.target
swap.target
cryptsetup.target
systemd-udevd.service
systemd-update-utmp.service
systemd-journal-flush.service
plymouth-read-write.service
. . .

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

[[step-3 -—- looking-at-a-unit-file]] === Шаг 3 - Просмотр блочного файла

Идя дальше, давайте заглянем внутрь файла сервисного модуля. Мы увидели файл служебного модуля MySQL в первой части этого учебного пособия, и вскоре мы снова будем его использовать, но сейчас давайте откроем другой файл служебного модуля, такой как sshd: 

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

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

Output[Unit]
Description=OpenSSH server daemon
After=syslog.target network.target auditd.service

[Service]
EnvironmentFile=/etc/sysconfig/sshd
ExecStartPre=/usr/sbin/sshd-keygen
ExecStart=/usr/sbin/sshd -D $OPTIONS
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
Restart=on-failure
RestartSec=42s

[Install]
WantedBy=multi-user.target

Этот файл сервисного модуля, как и файл конфигурации демона Upstart, прост и понятен.

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

Файл также показывает, что службаwanted наmulti-user.target, что означает, что цель загрузит эту службу, но она не завершится или не завершится с ошибкой в ​​случае сбоя sshd.

Посколькуmulti-user.target является целью по умолчанию, предполагается, что демон sshd запускается во время загрузки.

Выйдите из редактора.

[[step-4 -—- testing-mysql-startup-behavior-at-boot]] === Шаг 4 - Тестирование поведения MySQL при запуске при загрузке

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

В последнем разделе мы выполнили команду, чтобы подтвердить, чтоmysqld.service нуженmulti-user.target. Когда мы перечислили содержимое каталога/etc/systemd/system/multi-user.target.wants/, мы увидели символическую ссылку, указывающую на исходную служебную единицу под/usr/lib/systemd/system/.

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

sudo systemctl disable mysqld.service

Теперь запустите эту команду, чтобы проверить, нужен ли MySQL по-прежнемуmulti-user.target: 

sudo systemctl show --property "Wants" multi-user.target | fmt -10 | grep mysql

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

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

Ссылка не существует: 

Outputls: cannot access /etc/systemd/system/multi-user.target.wants/mysql*: No such file or directory

Если хотите, попробуйте перезагрузить сервер. MySQL не должен подходить.

Теперь включите сервис: 

sudo systemctl enable mysqld.service

Ссылка вернется: 

sudo ls -l /etc/systemd/system/multi-user.target.wants/mysql*
Outputlrwxrwxrwx 1 root root 38 Aug  1 04:43 /etc/systemd/system/multi-user.target.wants/mysqld.service -> /usr/lib/systemd/system/mysqld.service

(Если вы перезагружались раньше, вы должны снова запустить MySQL.)

Как видите, включение или отключение службы systemd создает или удаляет символическую ссылку из каталога цели по умолчаниюwants.

[[step-5 -—- testing-mysql-startup-behavior-on-crash]] === Шаг 5. Тестирование поведения при запуске MySQL при сбое

MySQL в настоящее время автоматически запускается после сбоя. Давайте посмотрим, как это отключить.

Откройте файл сервисного модуля MySQL в редакторе: 

sudo nano /etc/systemd/system/multi-user.target.wants/mysqld.service

После информации заголовка содержимое файла выглядит так:

/etc/systemd/system/multi-user.target.wants/mysqld.service

[Unit]
Description=MySQL Community Server
After=network.target
After=syslog.target

[Install]
WantedBy=multi-user.target
Alias=mysql.service

[Service]
User=mysql
Group=mysql

# Execute pre and post scripts as root
PermissionsStartOnly=true

# Needed to create system tables etc.
ExecStartPre=/usr/bin/mysql-systemd-start pre

# Start main service
ExecStart=/usr/bin/mysqld_safe

# Don't signal startup success before a ping works
ExecStartPost=/usr/bin/mysql-systemd-start post

# Give up if ping don't get an answer
TimeoutSec=600

Restart=always
PrivateTmp=false

Как мы видели в Части 1, значение параметраRestart установлено наalways (для sshd это было установлено только наon-failure). Это означает, что служба MySQL будет перезапущена для чистых или нечистых кодов выхода или тайм-аутов.

man page for systemd service показывает следующую таблицу параметров перезапуска:

Настройки перезапуска / причины выхода no всегда при успехе отказ ненормальный прерывание сторожевой пес

Чистый код выхода или сигнал

X

X

Нечистый код выхода

X

X

Нечистый сигнал

X

X

X

X

Тайм-аут

X

X

X

Сторожевая собака

X

X

X

X

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

Закомментируйте директиву Restart, сохраните файл и выйдите из редактора. Это отключит поведение перезапуска.

/etc/systemd/system/multi-user.target.wants/mysqld.service

# Restart=always

Затем перезагрузите демон systemd, а затем перезапустите службуmysqld: 

sudo systemctl daemon-reload
sudo systemctl restart mysqld.service

Затем найдите основной PID службы, выполнив эту команду: 

sudo systemctl status mysqld.service
Output. . .
Main PID: 11217 (mysqld_safe)

Используя командуkill -9, уничтожьте основной PID, используя свой собственный номер. 

sudo kill -9 11217

Повторный запускsudo systemctl status mysqld.service покажет, что служба не работает: 

sudo systemctl status mysqld.service
Outputmysqld.service - MySQL Community Server
   Loaded: loaded (/usr/lib/systemd/system/mysqld.service; enabled)
   Active: failed (Result: signal) since Sun 2015-06-21 02:28:17 EDT; 1min 33s ago
  Process: 2566 ExecStartPost=/usr/bin/mysql-systemd-start post (code=exited, status=0/SUCCESS)
  Process: 2565 ExecStart=/usr/bin/mysqld_safe (code=killed, signal=KILL)
  Process: 2554 ExecStartPre=/usr/bin/mysql-systemd-start pre (code=exited, status=0/SUCCESS)
 Main PID: 2565 (code=killed, signal=KILL)

Jun 21 02:20:09 test-centos7 systemd[1]: Starting MySQL Community Server...
Jun 21 02:20:09 test-centos7 mysqld_safe[2565]: 150621 02:20:09 mysqld_safe Logging to '/var/log/mysqld.log'.
Jun 21 02:20:09 test-centos7 mysqld_safe[2565]: 150621 02:20:09 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
Jun 21 02:20:10 test-centos7 systemd[1]: Started MySQL Community Server.
Jun 21 02:28:16 test-centos7 systemd[1]: mysqld.service: main process exited, code=killed, status=9/KILL
Jun 21 02:28:17 test-centos7 systemd[1]: Unit mysqld.service entered failed state.

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

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

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

Вот как можно настроить собственный сервис systemd для автоматического запуска после сбоя. Все, что нам нужно сделать, это добавить дополнительную директиву дляRestart (и, возможно,RestartSec) в раздел[Service] файла служебной единицы.

Заключение

Так вот, как Linux обрабатывает запуск службы. Мы видели, как работают процессы инициализации System V, Upstart и systemd и как они связаны с автоматическим запуском службы после перезагрузки или сбоя.

Декларативный синтаксис файлов конфигурации Upstart или файлов системного модуля является улучшением по сравнению с тайными сценариями инициализации System V.

Работая со своей собственной средой Linux, проверьте версию своего дистрибутива и посмотрите, какой демон init он поддерживает.

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

Related