Использование inittab для обеспечения работы sshd (и других важных элементов) - есть ли недостатки?
После того, как мне удалось убить sshd на удаленной машине (запустив скрипт, который использовал всю доступную память на машине, упс...), к которому у меня нет доступа, кроме посещения хостинга для [1], я обдумывал способы обеспечения этот sshd всегда работает.
Кроме хакерского задания cron перезапускать sshd каждые n минут или часов, использование inittab для запуска init для поддержания работы sshd кажется хорошей идеей.
Есть ли недостатки этого подхода? Казалось бы, что-то, что было бы разумно для дистрибутивов Linux по умолчанию, поскольку sshd часто является единственным доступным методом доступа для машины.
Кроме того, есть ли другие демоны, для которых я должен использовать этот подход? Возможно, агент мониторинга, такой как nrpe для nagios?
[1] Да, карты управления или сетевой выключатель были бы хорошей идеей, но в то время они считались "ненужными"...
8 ответов
Есть несколько реализаций этой идеи. Upstart используется Ubuntu и может перезапускать сервисы, если они умирают, Solaris 10 имеет средство управления сервисами, runit является кроссплатформенным и, как уже упоминалось, daemontools.
Я не могу думать ни о какой другой причине, чтобы не делать inittab, кроме того, что перезапуск sshd после обновления немного более неудобен.
Помимо этого: интересная идея.
Вы можете сказать linux OOM killer не убивать sshd, google для oom_adj для более подробной информации, или посмотрите, например, здесь руководство по rhel
Monit - это демон мониторинга, предназначенный именно для того, что вы хотите здесь сделать.
Интересная идея
Я не пробовал ничего подобного, но я бы проверил, в какое время в процессе загрузки запускаются вещи из inittab. Если это слишком рано, возможно, сеть не работает.
Есть преимущества наличия сервисов, которые должны быть надежными в рамках схемы, обеспечивающей их постоянную работу. Я предпочитаю использовать daemontools самостоятельно по причинам, указанным здесь: http://cr.yp.to/daemontools/faq/create.html
Я не запускал ssh таким образом, но я был бы достаточно счастлив сделать это, если бы думал, что мое текущее управление SSH не будет работать. Что касается вашей проблемы "нехватки памяти", вы можете деприоритизировать некоторые процессы, такие как sshd, чтобы они не были убиты убийцей OOM в пользу программы, которая на самом деле вызывает проблему.
Как другие заметили до меня, использование существующего инструмента, такого как daemontools или monit, вероятно, будет самым умным путем. Вы не можете использовать inittab для создания sshd, когда он разветвляется на фон, и init попытается запустить несколько sshd. Скорее всего, вы получите сообщения "init: re-spawn слишком быстро".
Возможно, вы захотите написать небольшой скрипт мониторинга, который будет работать в цикле и убедиться, что оригинальный sshd (тот, который принимает соединения и разветвляется для обработки сеансов) все еще работает. Если он потерпит неудачу, просто используйте системный скрипт init для его повторного запуска.
Просто обратите внимание, что если ваш sshd убит обработчиком ядра OOM, то нет никаких гарантий, что ваш sshd переживет перезапуск...
Единственная проблема, которую я могу предвидеть, это попытка возродиться с ошибкой конфигурации.
Я думал, что вы можете оценить ограничение возрождения, но я не могу найти какую-либо документацию, подтверждающую это.