Стандартный или лучший способ поддержать процесс, запущенный init.d

14

Я ищу стандартный способ или лучшую практику, чтобы поддерживать запуск демона с помощью init.dсценария оболочки.

Или, что еще лучше, есть ли способ сохранить жизнь напрямую /etc/init.d?

В частности, у меня есть демон с именем dtnd with и бесконечный цикл, который ищет неожиданно завершившийся процесс, если он есть, демон снова их разбудит. Кроме того, я использую инструмент start-stop-daemon для запуска прецессии от определенного пользователя системы.

Я хочу запустить этот демон dtnd при запуске. Чтобы добиться такого поведения, я создал скрипт init.d, который «оборачивает» файл dtnd с помощью команд start, stop и status.

У меня есть 2 вопроса, которые я хотел бы решить:

  1. Есть ли способ добиться поддержания какого-то процесса из сценария оболочки init.d. Это стандартная / лучшая практика?

  2. Рекомендуется поддерживать процесс с бесконечным циклом? Я полагаю, что respawnдля достижения этой цели лучше использовать какую-нибудь команду . Это правильно?

Я знаю о существовании respawnкоманды. Я думаю, что это то, что мне нужно, но я не понимаю рабочий процесс между /etc/init.d/и /etc/init. Может кто-нибудь мне помочь?

Обратите внимание , что у меня нет ни inittab выскочки (я только разрешено использовать /etc/init, /etc/init.d, cronи системные инструменты , как start-stop-daemon. Я имею в виду, только инструменты по умолчанию)

Большое вам спасибо за ваше время!

debian init.d daemon startup init Адриан Антунес
источник
возможный дубликат сценария Shell для выполнения чего-либо, когда один из демонов умирает?
ewwhite

Ответы:

13

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

Systemd может автоматически поддерживать работу службы; никаких других инструментов не требуется. Просто убедитесь, что Restart=alwaysэто установлено в разделе служебного файла [Service].

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

[Service]
Restart=always
#...everything else...

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

Майкл Хэмптон
источник
2
В то время как будущее показывает более гибкие варианты, это заботится о текущей окружающей среде / условиях? Установка инструмента, кажется, путь наименьшего сопротивления по сравнению с изменением / модернизацией распределения погрузчика.
ewwhite
@ewwhite Это зависит. Debian имеет systemd начиная с wheezy, но он не был инициализацией по умолчанию. Это должно быть по умолчанию от Джесси. И поскольку наш пользователь принял ответ, я предполагаю, что он уже использовал systemd по другой причине (или имел разрешение на его установку).
Майкл Хэмптон
systemdКажется, init.dсценарий сброса и база на*.service
yurenchen
2
Вместо непосредственного редактирования используйте безопаснее systemctl edit myservice, затем systemctl daemon-reloadи перезапустите myservice.
Пабло А
@PabloBianchi Создание переопределения хорошо, если вы переопределяете модуль существующей службы. Если вы создаете юнит с нуля, как это сделал OP, то это бессмысленно.
Майкл Хэмптон
3

Вы можете добавить его с /etc/inittabпомощью respawn:

d1:2345:respawn:/path/to/your/first_daemon arg1 arg2
d2:2345:respawn:/path/to/your/second_daemon arg1 arg2

Это грязный хак, но я успешно использовал его в прошлом на старых системах sysv-init.

Деннис Каарсемакер
источник
Но разве демоны не вызывают cal setsid () и fork () для запуска в фоновом режиме?
Symcbean
Спасибо! Как вы говорите, это грязный хак, но это работает. В любом случае я предпочитаю использовать systemd. Теперь я знаю о его существовании.
Адриан Антунес
Это не работает на RHEL6. Похоже, что утилита респауна недоступна.
Джидиуф
2

Ну, это одна из главных причин, почему Debian переходит на systemd.

sysvinit (/etc/init.d) не может определить, не работает ли служба или не отвечает. Это означает, что вы должны отслеживать эти службы и расширяться, если служба больше не выполняет свою работу.

вероятно, проще всего было бы выполнить миграцию на другой демон-обработчик, такой как systemd (по умолчанию в RHEL7, будет по умолчанию в следующем Debian и Ubuntu lts), upstart (по умолчанию в RHEL6, Ubuntu 12.04 и 14.04), daemontools (как упомянуто, разработано с помощью DJB) или что-то еще.

работа по поддержанию сервиса будет PITA в sysvinit.

janaurka
источник
1

Лучшая практика - убедиться, что ваши демоны НЕ ОСТАНАВЛИВАЮТСЯ в первую очередь.

В противном случае вы можете захотеть взглянуть на Djb в DaemonTools

symcbean
источник
3
Конечно, лучшая практика - следить за тем, чтобы мои демоны не останавливались. Но есть много приложений, которые следуют подходу if-I-stop-wake-me, как apache2, mysql, samba, pulseaudio ... Я искал daemontools и кажется хорошим подходом. К сожалению, мне не разрешено устанавливать внешние инструменты. Мне нужно сделать это используя скрипты bash или start-stop-daemon и init.d config.
Адриан Антунес
1

Стандартный подход для меня - использовать для этого утилиту Monit .

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

ewwhite
источник
1
Привет, я должен убедиться, что мое приложение работает. К сожалению, мне не разрешено устанавливать внешние инструменты. Мне нужно сделать это используя скрипты bash или start-stop-daemon и init.d config.
Адриан Антунес
2
@ AdriánAntúnez Если вам не разрешено устанавливать инструменты, необходимые для вашей работы, вам следует как можно скорее решить эту проблему.
Майкл Хэмптон
@ AdriánAntúnez Вы просили «стандарт». Монит довольно хорошо известен. Вы просили «лучших» ... Ваше ограничение носит скорее политический характер. Почему вам не разрешено устанавливать программное обеспечение?
ewwhite
1
Это не ненужный инструмент или зависимость, если он делает то, что вы хотите .
ewwhite
1
@ewwhite Извините, я имел в виду избегать зависимостей от внешних инструментов.
Адриан Антунес