일정 시간 동안 스크립트를 실행한 후 cron 작업이 종료됩니다.

일정 시간 동안 스크립트를 실행한 후 cron 작업이 종료됩니다.

하루 중 서로 다른 시간에 여러 cronjob이 실행되고 있지만 특정 cronjob 중 하나가 예상대로 실행되지 않고 잠시 후에 종료됩니다.

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

backdoor.py 스크립트는 for 루프에서 각 파일을 하나씩 실행하며 1시간 또는 약 25개 파일 후에 갑자기 종료됩니다. 로그 파일에는 오류 메시지나 종료 메시지가 없습니다.

그러나 수동으로 실행하면 원활하게 실행됩니다.

이 특정 cronjob이 실패한 이유를 어떻게 디버깅할 수 있나요?

운영 체제: 리눅스-데비안

답변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씩 증가시키는지 항상 궁금했습니다. 부모-자식 관계가 크론 작업을 어떻게 종료하는지 알아보기 위해 프로세스 트리를 조사했습니다.

$ 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)이 시작됩니다.

crontab 명령 자체를 실행하기 위해 하위 쉘(pid 3809)을 실행합니다.

pid 3810은 crontab에서 사용자가 정의한 명령입니다.

Pid 3914는 프로세스 트리의 이 부분을 보고합니다(685가 해당 매개변수에 있으므로 자체적으로 보고함). 먼저 실제 pid를 찾아야 했습니다("787"의 전체 ps 목록을 보려면 grep).

685, 3808 또는 3809는 자식에게 프로세스를 중지하라는 신호를 보낼 수 있지만 cron이 이를 수행하는 것을 본 적이 없습니다(프로세스가 CPU를 초과하고 셸에서 신호를 보내는 것을 본 적이 있습니다). 그러나 이 정보를 사용하여 일부 디버깅을 설계할 수 있습니다. 예를 들어 Python 코드를 실행하고 free, ps10초마다 로그에 추가하고, 메모리나 CPU가 문제인지 확인합니다.

관련 정보