Почему процессы, порожденные cron, в конечном итоге прекращают свое существование?

Потому что они не были предметом системного вызова wait(2).

Поскольку кто-то может ждать эти процессы в будущем, ядро ​​не сможет полностью избавиться от них или не сможет выполнить системный вызов wait, потому что у него больше не будет статуса выхода или свидетельства его существования. .

Когда вы запускаете его из оболочки, ваша оболочка все равно перехватывает SIGCHLD и выполняет различные операции ожидания, поэтому ничто не остается неработоспособным надолго.

Но cron не находится в состоянии ожидания, он спит, поэтому несуществующий дочерний элемент может какое-то время оставаться рядом, пока cron не проснется.

Обновление: Отвечаю на комментарий... Хм. Мне удалось продублировать проблему:

 PPID   PID  PGID  SESS COMMAND
    1  3562  3562  3562 cron
 3562  1629  3562  3562  \_ cron
 1629  1636  1636  1636      \_ sh <defunct>
    1  1639  1636  1636 sleep

Итак, что произошло, я думаю:

• cron forks и cron-потомок запускает оболочку
• оболочка (1636) запускает sid и pgid 1636 и запускает сон
• оболочка завершает работу, SIGCHLD отправляется в cron 3562
• сигнал игнорируется или неправильно обрабатывается
• shell turns zombie. Note that sleep is reparented to init, so when the sleep exits init will get the signal and clean up. I'm still trying to figure out when the zombie gets reaped. Probably with no active children cron 1629 figures out it can exit, at that point the zombie will be reparented to init and get reaped. So now we wonder about the missing SIGCHLD that cron should have processed.
  • It isn't necessarily vixie cron's fault. As you can see here, libdaemon installs a SIGCHLD handler during daemon_fork(), and this could interfere with signal delivery on a quick exit by intermediate 1629

    Теперь я даже не знаю, собран ли vixie cron в моей системе Ubuntu с помощью libdaemon, но, по крайней мере, у меня есть новая теория. :-)

на мой взгляд, это вызвано процессом CROND (порожденным crond для каждой задачи), ожидающим ввода на стандартный ввод, который передается на стандартный вывод/stderr команды в crontab. Это сделано потому, что cron может отправлять результирующие выходные данные пользователю по почте.

Таким образом, CROND ожидает EOF до тех пор, пока пользовательская команда и все порожденные ею дочерние процессы не закроют канал. Если это будет сделано, CROND продолжит работу с оператором ожидания, а затем несуществующая пользовательская команда исчезнет.

Поэтому я думаю, что вам нужно явно отключить каждый порожденный подпроцесс в вашем скрипте из канала (например, перенаправив его в файл или /dev/null.

поэтому следующая строка должна работать в crontab:

* * * * * ( /tmp/launcher.sh /tmp/tester.sh &>/dev/null & ) 

Я подозреваю, что cron ожидает завершения всех подпроцессов в сеансе. См. wait(2) относительно отрицательных аргументов pid. Вы можете увидеть SESS с помощью:

ps faxo stat,euid,ruid,tty,tpgid,sess,pgrp,ppid,pid,pcpu,comm

Вот что я вижу (отредактировано):

STAT  EUID  RUID TT       TPGID  SESS  PGRP  PPID   PID %CPU COMMAND
Ss       0     0 ?           -1  3197  3197     1  3197  0.0 cron
S        0     0 ?           -1  3197  3197  3197 18825  0.0  \_ cron
Zs    1000  1000 ?           -1 18832 18832 18825 18832  0.0      \_ sh <defunct>
S     1000  1000 ?           -1 18832 18832     1 18836  0.0 sleep

Обратите внимание, что sh и sleep находятся в одном и том же SESS.

Используйте команду setsid(1). Вот tester.sh:

#!/bin/bash
setsid sleep 27 # the real script launches a compiled C program in the background

Обратите внимание, что & вам не нужен, setsid помещает его в фоновый режим.

Я бы порекомендовал вам решить проблему, просто отказавшись от двух отдельных процессов: пусть launcher.sh сделает это в своей последней строке:

exec "$@"

Это избавит от лишнего процесса.

Я нашел этот вопрос, когда искал решение с аналогичной проблемой. К сожалению, ответы на этот вопрос не решили мою проблему.

Уничтожение несуществующего процесса не вариант, так как вам нужно найти и убить его родительский процесс. В итоге я убил несуществующие процессы следующим образом:

ps -ef | grep '<defunct>' | grep -v grep | awk '{print "kill -9 ",$3}' | sh

В «grep ''» вы можете сузить поиск до определенного несуществующего процесса, который вам нужен.

Я проверял одну и ту же проблему так много раз. И, наконец, у меня есть решение. Просто укажите «/bin/bash» перед сценарием bash, как показано ниже.

* * * * * /bin/bash /tmp/launcher.sh /tmp/tester.sh