☰

cron 作业在执行脚本一段时间后终止

tag-icon • tag-icon linux debian cron jobs
cron 作业在执行脚本一段时间后终止

我有几个 cronjobs 在一天中的不同时间运行，但一个特定的 cronjobs 没有按预期运行并在一段时间后终止。

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

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

但当手动执行时，运行很顺利。

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

操作系统：linux-debian

答案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那么您将获得包装器报告的退出状态和最终消息。有了这些信息，您就可以更好地集中调查。

答案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 在其参数中）。我必须首先找到实际的 pid（通过 grep 查找“787”的完整 ps 列表）。

685、3808 或 3809 中的任何一个都可以向其子进程发出信号以停止进程，但我从未见过 cron 完成此操作（我见过进程超过 CPU 并由 shell 发出信号）。但是，您可以使用此信息设计一些调​​试：例如，运行free您ps的 python 代码，每 10 秒附加到日志中，并查看内存或 CPU 是否成为问题。

相关内容