У меня особая проблема при запуске текущих (сервисных) процессов либо из полномасштабного сценария init.d (стиль SysV), либо из простого однострочного вызова из файла rc.local, например:
su someuser -c "/home/someuser/watchdog.sh &"
Где watchdog.sh содержит это:
#!/bin/bash
cd /home/someuser
until ./eventMonitoring.py
do
echo "Program crashed with exit code $?. Starting again..." >&2
sleep 1
done
У меня всегда остается один дополнительный процесс в списке процессов:
UID PID PPID C SZ RSS PSR STIME TTY TIME CMD
root 3048 1 0 1024 620 1 20:04 ? 00:00:00 startpar -f -- rc.local
Если я запустил его из моего сценария init.d (источник: https://github.com/ivankovacevic/userspaceServices)
Я получаю тот же процесс, но это startpar -f - userspaceServices
Что это за процесс? Почему нет упоминания о -f аргумент при просмотре страницы руководства startpar? Что я делаю неправильно с точки зрения запуска процесса при загрузке от имени другого пользователя, что этот странный процесс startpar также необходимо оставить (или запустить)? Почему этого процесса нет ни в одном другом скрипте init.d?
Может ли кто-нибудь помочь мне пролить свет на эту тему?
Примечание. Моя система - Debian Wheezy 7.4.0.
ОБНОВИТЬ !
Я открыл новый вопрос по stackoverflow, чтобы обсудить startpar поведение с точки зрения программиста:
https://stackoverflow.com/questions/22840360/figuring-out-what-startpar-c-sysvinit-is-doing
Мое дальнейшее расследование привело меня к решению. Итак, теперь я знаю, как это правильно делать, но все еще не понимаю, почему startpar вел себя так же. Так что, если кто-то захочет вмешаться и объяснить это, я более чем готов принять этот ответ, чем этот.
В основном проблема заключалась в том, что я вызывал сценарии без перенаправления (или закрытия) стандартного ввода, стандартного вывода и стандартной ошибки в файл или в / dev / null и по какой-то причине startpar("используется для параллельного запуска нескольких сценариев уровня выполнения") процесс, который, насколько я понимаю, запускает другие процессы во время загрузки, был заблокирован в этом моем скрипте из-за этого. Он запустил мой скрипт, но сам не завершил работу и остался на этапе, показанном в списке процессов как:
UID PID PPID C SZ RSS PSR STIME TTY TIME CMD
root 3048 1 0 1024 620 1 20:04 ? 00:00:00 startpar -f -- rc.local
Исходный код startpar это здесь: http://svn.savannah.nongnu.org/viewvc/startpar/trunk/startpar.c?root=sysvinit&view=markup
Я просмотрел его и сделал свой первоначальный анализ в новом вопросе, который я разместил в stackoverflow. Найдите ссылку в ОБНОВИТЬ Я добавил сюда свой вопрос.
Последнее решение, которое я использовал, таково:
su someuser -c "nohup some_script.sh >/dev/null 2>&1 &"
вс - заменить идентификатор пользователя на какой-то пользователь
-c - аргумент su для запуска указанной команды
нету - Запустите команду, невосприимчивую к зависаниям. Чтобы предотвратить случаи, когда родительский процесс завершит дочерний процесс. Добавил сюда на всякий случай. Но на самом деле не имеет никакого эффекта в моем конкретном случае. Необходимость этого зависит от окружающей среды (отметьте купил)
> / dev / null - Перенаправить стандартный вывод в ничто, в основном отключив его.
2> & 1 - Перенаправить стандартный вывод ошибок (2) на стандартный вывод (1), который перенаправляется на нуль
& - отсоединить от фона, это перенаправит стандартный ввод также в / dev / null.
Глядя на файловые дескрипторы других известных демонов, работающих в моей системе, я вижу, что перенаправление на / dev / null - обычное дело. И только некоторые процессы-демоны фактически полностью закрыли stdin, stdout, stderr. Этого можно достичь, например:
su someuser -c "some_script.sh 0<&- 1>&- 2>&- &"
В практическом смысле это одно и то же, и это то, что необходимо (в любом случае), чтобы чисто отделить процесс как фоновый демон.