Назад | Перейти на главную страницу

Демонический процесс завершается при закрытии оболочки

У меня есть сценарий, который запускает процесс демона, а затем спит в течение 20 секунд. Если я запускаю сценарий на SLES11 SP1 или RHEL6, то после выхода из сценария процесс все еще выполняется.

Если я запускаю сценарий на SLES11 SP3 или RHEL6.3, то после выхода из сценария процесс больше не выполняется. Процесс продолжает работать в течение всего 20-секундного сна и завершается при выходе из процесса.

Скрипт запускается через expect, поэтому вся оболочка скрипта завершает работу вместе с процессом. Очевидно, если бы это не был демон, он запускался, я бы не удивился. Кроме того, я подозреваю, что проблема не в версии ОС, а в различии в том, как мы устанавливаем новые серверы (хотя не знаю, в чем эти различия, старые серверы были установлены много лет назад).

В течение 20 секунд процесс запускается, если я сделаю ps, я получу следующее:

root      4699     1  0 15:14 pts/2    00:00:00 sudo -u openmq /opt/PacketPortal/openmq/default/bin/imqbrokerd -bgnd -autorestart -silent -port 7676 -Dimq.service.activelist=admin,ssljms -D
openmq    4701  4699  0 15:14 pts/2    00:00:00 /bin/sh /opt/PacketPortal/openmq/default/bin/imqbrokerd -bgnd -autorestart -silent -port 7676 -Dimq.service.activelist=admin,ssljms -Dimq.ssl
openmq    9095  9063 54 16:21 pts/2    00:00:02 /usr/java/latest/bin/java -cp /opt/PacketPortal/openmq/default/bin/../lib/imqbroker.jar:/opt/PacketPortal/openmq/default/bin/../lib/imqutil.jar:/opt/PacketPortal/ope

Тот факт, что родительский процесс 4699 равен 1, кажется мне, наводит на мысль, что процесс был правильно демонизирован. Однако после завершения сценария ожидания как 4699, так и 4701 будут уничтожены. Что может быть причиной этого?

ОБНОВИТЬ

Я распечатал тот же результат на работающих серверах. Во время 20-секундного сна я получаю:

openmq   18652     1  0 15:44 pts/1    00:00:00 /bin/sh /opt/PacketPortal/openmq/default/bin/imqbrokerd -bgnd -autorestart -silent -port 7676 -Dimq.service.activelist=admin,ssljms -Dimq.ssljms.tls.port=7680
openmq   18686 18652  8 15:44 pts/1    00:00:02 /usr/java/latest/bin/java -cp /opt/PacketPortal/openmq/default/bin/../lib/imqbroker.jar:/opt/PacketPortal/openmq/default/bin/../lib/imqutil.jar:/opt/PacketPortal/ope

После 20-секундного сна я получаю:

openmq   18652     1  0 15:44 ?        00:00:00 /bin/sh /opt/PacketPortal/openmq/default/bin/imqbrokerd -bgnd -autorestart -silent -port 7676 -Dimq.service.activelist=admin,ssljms -Dimq.ssljms.tls.port=7680
openmq   18686 18652  5 15:44 ?        00:00:02 /usr/java/latest/bin/java -cp /opt/PacketPortal/openmq/default/bin/../lib/imqbroker.jar:/opt/PacketPortal/openmq/default/bin/../lib/imqutil.jar:/opt/PacketPortal/ope

После выхода из сценария он отключает управляющий терминал. Интересно, почему этого не происходит на новых серверах.

ОБНОВИТЬ

Вот раздел скрипта, который фактически запускает OpenMQ. Флаг -bgnd - это то, что должно демонизировать его.

sudo -u openmq $IMQ_HOME/bin/$EXECUTABLE -bgnd $BROKER_OPTIONS $ARGS > /dev/null 2>&1 &

ОБНОВИТЬ

Случайно обнаружил какое-то действительно странное поведение. Если я изменю команду на:

sudo -u openmq sldkhglksj; $IMQ_HOME/bin/$EXECUTABLE -bgnd $BROKER_OPTIONS $ARGS > /dev/null 2>&1 &

Тогда я получаю sldkhglksj: command not found конечно но ... процесс openmq не убивается. Если я возьму ту сдачу, она погибнет.

ОБНОВИТЬ

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

Возможно, вы столкнулись с этой проблемой, описанной здесь: https://access.redhat.com/knowledge/solutions/180243.

В нем говорится, что поведение sudo для действий, подобных описанному вами, изменилось в версии, поставляемой с RHEL / CentOS 6.3 (sudo-1.7.4p5-11.el6.x86_64). Тот факт, что вы видите различное поведение между RHEL 6 и 6.3 и что это связано с sudo, является причиной, по которой я указываю на это.

Некоторые варианты, которые стоит попробовать (у меня нет 100% ответа, просто выкидываю идеи):

  • Если у вас есть доступ на уровне root, что, похоже, есть у вас, попробуйте запустить скрипт без использования sudo, что-то вроде su -c '/opt/PacketPortal/openmq/default/bin/imqbrokerd -bgnd -autorestart -silent -port 7676 -Dimq.service.activelist=admin,ssljms -D' - openmq - Видеть http://www.linfo.org/su.html для получения дополнительной информации
  • Установите старую версию sudo чтобы обойти это (хакерский, я знаю, но вы можете построить / установить его во временном месте, чтобы проверить)
  • Посмотрите в huponexit shopt в ответе, на который ссылается Массимо, это звучит многообещающе, если это не проблема sudo, о которой я упоминал выше

Попробуйте добавить disown на отдельной строке после того, как вы выполните фоновый процесс. Это должно помешать вашей оболочке отправлять сигналы любым дочерним процессам при выходе.

Вы можете префикс команды, которую хотите демонстрировать в сценарии:

  nohup command-that-you-want-to-demonize &

Затем, когда внешний скрипт завершится, программа продолжит работу.

Попробуйте добавить </dev/null в команду запуска.

Не уверен, как именно -bgnd flag должен быть фоновым для вашего процесса, но процессы могут умереть, если их стандартный ввод будет потерян, что именно происходит, когда вы теряете соединение ssh. Вы уже отбрасываете весь вывод в битовый пакет, возможно, вы захотите убедиться, что ввода нет.

Я не могу не объяснить такое изменение поведения, но предлагаю просто смириться с этим.