执行脚本时，cron作业在某个时候终止。

Question

我有几个任务在一天中的不同时间运行，但是一个特定的cron任务没有按预期运行，并且在某个时候被终止。

0 0  * * * python3 /scratch/pyscripts/backdoor.py --user SEKHAR >> /scratch/tlog/backdoor.log 2>&1;

backdoor.py脚本将在for循环中逐一执行每个文件，在1小时后或在执行25个文件时突然终止。日志文件中既没有错误消息，也没有退出消息。

但是，当它手动执行时，它运行得很平稳。

如何调试此特定cronjob失败的原因？

操作系统: linux-debian

Answer 1

我的cron作业可以持续几个小时，所以我不认为是cron固有的任何东西限制了您的任务。我的倾向是，是您的python任务本身崩溃了(但我很感激我不知道它在做什么，也不知道它是如何编写的，我确实看到您说它是从终端会话中正确运行的)。

我可能会通过为python作业本身创建一个包装器来解决识别意外终止的根本原因的问题。就像这样，

#!/bin/sh
#
exec 1>/scratch/tlog/backdoor.log 2>&1

dtStart=$(date +'%Y-%m-%d %H:%M')
printf "%s\tStarted at %s\n" "$dtStart" "$dtStart"

python3 /scratch/pyscripts/backdoor.py --user SEKHAR
ss=$?

dtStop=$(date +'%Y-%m-%d %H:%M')
printf "Uptime and load avg:%s\n" "$(uptime)"
printf "%s\tStarted at %s and stopped at %s with status %d\n\n" "$dtStop" "$dtStart" "$dtStop" $ss

这里的理由是，如果是cron终止任务，则不太可能得到“已完成”消息，但如果是python作业，则会得到包装器报告的退出状态和最终消息。有了这些信息，你就能更好地集中精力调查。

Answer 2

我一直在想，为什么每个cron任务都会将进程数增加3，我研究了过程树，以了解养育孩子会如何杀死cron任务。

$ crontab -l | grep 787
11 11 17 * * sleep 787
$ ps -ef | awk 'NR == 1 || /(685|380[0-9])/'
UID        PID  PPID  C STIME TTY          TIME CMD
root       685     1  0 10:31 ?        00:00:00 /usr/sbin/cron -f
root      3808   685  0 11:11 ?        00:00:00 /usr/sbin/CRON -f
paul      3809  3808  0 11:11 ?        00:00:00 /bin/sh -c sleep 787
paul      3810  3809  0 11:11 ?        00:00:00 sleep 787
paul      3914  3720  0 11:15 pts/1    00:00:00 awk NR == 1 || /(685|380[0-9])/
$ 

10:31是我的启动时间，所以进程685是我的初始cron守护进程。

对于每个作业，cron启动一个包装子CRON (这里是pid 3808 )，负责发送任何输出，记录结果等等。

它执行子shell (pid 3809)来运行crontab命令本身。

Pid 3810是用户在crontab中定义的命令。

Pid 3914正在报告流程树的这一部分(报告本身，因为685在其args中)。我必须首先找到实际的pids (通过为‘787’添加完整的ps列表)。

685,3808或3809中的任何一个都可以指示它的子进程删除一个进程，但我从未见过cron这样做(我看到一个进程超过CPU并被外壳发出信号)。但是，您可以使用以下信息设计一些调试:例如，运行free和ps作为您的python代码，每10秒附加到日志中，并查看内存或CPU是否成为一个问题。