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

14

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

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

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

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

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

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

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

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

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

— Адриан Антунес
источник

возможный дубликат сценария 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 Извините, я имел в виду избегать зависимостей от внешних инструментов.

— Адриан Антунес