Крон убивает порожденные процессы

Question

У меня настроено задание cron, которое запустит мой скрипт.

Цель этого сценария - убить процесс, который в данный момент выполняется, и запустить новую версию этого процесса (CHECKDB). CHECKDB должен быть запущен все время, поэтому у нас есть скрипт start_checkdb, который по сути представляет собой бесконечный цикл, который выполняет CHECKDB; если он падает, он остается в цикле, запускает его снова. [да, я понимаю, что это не лучшая практика, но дело не в этом]

Мой скрипт будет вызван cron без проблем, а затем он убьет CHECKDB без проблем. Насколько я могу судить, вызывается дочерний скрипт, который запускает резервное копирование CHECKDB, но каждый раз, когда я проверяю ps после запуска cron, процесс не запускается. Если я запускаю сценарий вручную в командной строке, под любой оболочкой, это не проблема: убивает CHECKDB и start_checkdb, запускает start_checkdb, который запускает CHECKDB.

Однако по какой-то причине, когда cron делает это, процесс никогда не запускается впоследствии. Он убивает живого и либо не запускает его, либо запускает и убивает.

Возможно ли, что когда cron завершит родительский процесс, он уничтожит вызванные дочерние процессы?

Я не знаю, имеет ли это значение, но это на Solaris 8.

Answer 1

Не могли бы вы уточнить ваше описание договоренности? Похоже, что при нормальных обстоятельствах оба start_checkdb и CHECKDB работают. Задание cron должно убить CHECKDB, а уже запущенная копия start_checkdb должна перезапустить его? Или задание cron убивает оба процесса и затем перезапускает start_checkdb? После выполнения задания cron какой процесс отсутствует - CHECKDB, start_checkdb или оба?

Сказав это, наиболее распространенными причинами того, что процесс работает из командной строки, но не работает cron, являются:

• Зависимость от правильной команды PATH (или другой переменной среды)
• Зависимость при запуске из правильного каталога
• Зависимость от запуска с tty.

Answer 2

Вы можете посмотреть на использование nohup в вашем скрипте cron при запуске checkdb. Такая вещь, как «команда nohup &», была бы нормальным способом запустить то, что вы хотели жить за пределами процесса запуска.