Каково максимально допустимое время запуска сценария запуска демона?
Каково максимально допустимое время запуска сценария запуска демона?
У меня есть сервер Tomcat, который запускается много времени, и я мог бы включить логику в сценарий запуска, чтобы проверить, успешно ли запущена служба или нет.
Тем не менее, у меня есть некоторые опасения по поводу потенциального бесконечного цикла запуска демона, который может повлиять даже на запуск системы, если он настроен для запуска во время загрузки.
Тем не менее, я хочу вернуть правильное сообщение о выходе (успех / неудача).
Я мог бы реализовать некоторую логику тайм-аута, но я понятия не имею, что считать приемлемым или недопустимым временем запуска для сценария демона.
Кроме того, не имеет большого смысла останавливать инициализацию других служб, пока эта служба еще инициализируется.
2 ответа
Для сценария запуска системы нет "максимально допустимого времени запуска". Тем не менее, для долго выполняющихся сценариев происходит то, что сценарий запуска обычно запускает программу, которая занимает много времени в качестве фонового процесса или даже процесса "at". Таким образом, это не позволяет медленному процессу занять много времени, прежде чем система будет "готова" к работе.
Как уже было сказано, для демона нет максимального или настраиваемого времени запуска. Если вы думаете, что демон вызывает запуск других демонов, вы можете изменить его последовательность запуска в конце.
Чтобы решить проблему, я могу придумать три способа сейчас.
1) Очевидным шагом будет включение журналов отладки для приложения. Я в основном работаю с RHEL и /etc/sysconfig/<daemon-name> где уровень журнала может быть установлен.
2) Когда вы вручную запускаете демон, запускайте его с помощью strace.
strace -ffttTo /tmp/daemon.out /etc/init.d/daemon start
Теперь в файле daemon.out обратите внимание на время, напечатанное в конце каждого системного вызова. Это в микросекундах. Выясните вызов, который потребляет большую часть времени.
Когда вы это выясните, снова запустите демон и на этот раз с ltrace. Теперь, когда вы знаете системный вызов обидчика, выясните, в какой библиотеке он застревает.
3) Написать сценарий системной записи. Это не так просто, если пользователь не имеет некоторого опыта в написании / отладке с помощью stap.
probe syscall.*
{
( (pid) == target() )
printf("%s\n",name)
}
Это покажет все системные вызовы, которые выбрасывает целевой pid.
ПРИМЕЧАНИЕ. - Во-первых, не ходите за скобами. Я только что упомянул об этом, потому что это потрясающий инструмент отладки для ядра, и я не видел упоминаний об этом на сайте (или, возможно, упустил из виду). Вам необходимо установить пакеты kernel-debuginfo, kernel-debuginfo-common, kernel-devel, systemtap. Затем запустите скрипт как
stap <script_name.stp> -x pid
Мы можем дополнительно использовать данный системный вызов.