crontab일정에 따라 또는 예상대로 스크립트가 실행되지 않는 경우가 종종 있습니다. 그 이유는 여러 가지가 있습니다.
- 잘못된 crontab 표기법
- 권한 문제
- 환경 변수
이 커뮤니티 위키는 crontab스크립트가 예상대로 실행되지 않는 주요 이유를 모으는 것을 목표로합니다 . 각 이유를 별도의 답변으로 작성하십시오.
답변 당 하나의 이유 (실행되지 않은 이유에 대한 세부 사항)를 포함시키고 해당 이유에 대한 수정 사항을 포함하십시오.
셸에서 예상대로 실행되지만 cron에서 잘못 실행하는 명령과 같은 cron 관련 문제 만 작성하십시오.
답변
다른 환경
Cron은 최소한의 환경 변수 세트를 작업에 전달합니다. 차이점을 보려면 다음과 같이 더미 작업을 추가하십시오.
* * * * * env> /tmp/env.output
/tmp/env.output생성 될 때 까지 기다린 다음 작업을 다시 제거하십시오. 이제 일반 터미널에서 실행 /tmp/env.output결과와 내용을 비교하십시오 env.
여기서 일반적인 “gotcha”는 PATH환경 변수가 다릅니다. 아마 당신의 cron 스크립트는에서 somecommand찾은 명령 /opt/someApp/bin을 사용할 것 PATH입니다 /etc/environment. cron은 PATH해당 파일을 무시 하므로 somecommandcron으로 실행할 때 스크립트 실행 이 실패하지만 터미널에서 실행할 때는 작동하지 않습니다. 의 변수 /etc/environment가 cron 작업으로 전달 된다는 점은 주목할 가치 가 있습니다 PATH.
그 문제를 해결하려면 PATH스크립트 상단에 자신의 변수를 설정하십시오 . 예 :
#!/bin/bash
PATH=/opt/someApp/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
# rest of script follows
일부는 모든 명령에 대한 절대 경로를 대신 사용하는 것을 선호합니다. 나는 그것을 반대하는 것이 좋습니다. 다른 시스템에서 스크립트를 실행하려는 경우 해당 시스템에서 명령이 /opt/someAppv2.2/bin대신 실행되는 경우를 고려하십시오 . 당신은 대체 전체 스크립트를 통해 가야 할 것 /opt/someApp/bin으로 /opt/someAppv2.2/bin대신 스크립트의 첫 번째 줄에 작은 편집을하는.
또한 crontab 파일에서 PATH 변수를 설정하면 모든 cron 작업에 적용됩니다. 예 :
PATH=/opt/someApp/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
15 1 * * * backupscript --incremental /home /root
답변
내 최고 문제 : crontab파일 끝에 줄 바꿈을 추가하는 것을 잊어 버린 경우 . 즉, crontab 파일은 빈 줄로 끝나야합니다.
아래는이 문제에 대한 매뉴얼 페이지의 관련 섹션입니다 ( man crontab끝으로 건너 뛰기).
Although cron requires that each entry in a crontab end in a newline
character, neither the crontab command nor the cron daemon will detect
this error. Instead, the crontab will appear to load normally. However,
the command will never run. The best choice is to ensure that your
crontab has a blank line at the end.
4th Berkeley Distribution 29 December 1993 CRONTAB(1)
답변
Cron 데몬이 실행되고 있지 않습니다. 몇 달 전에이 문제를 해결했습니다.
유형:
pgrep cron
숫자가 표시되지 않으면 cron이 실행되고 있지 않은 것입니다. sudo /etc/init.d/cron startcron을 시작하는 데 사용할 수 있습니다.
편집 : /etc/init.d를 통해 init 스크립트를 호출하는 대신 서비스 유틸리티를 사용하십시오.
sudo service cron start
편집 : 또한 현대 리눅스에서 systemctl을 사용할 수 있습니다.
sudo systemctl start cron
답변
스크립트는에는 파일 이름 cron.d/, cron.daily/, cron.hourly/, 등, 점 (포함되지 않아야합니다 .그렇지 않으면 실행-부분을 건너 뛸 것입니다).
run-parts (8)를 참조하십시오.
If neither the --lsbsysinit option nor the --regex option is given then
the names must consist entirely of upper and lower case letters, dig‐
its, underscores, and hyphens.
If the --lsbsysinit option is given, then the names must not end in
.dpkg-old or .dpkg-dist or .dpkg-new or .dpkg-tmp, and must belong to
one or more of the following namespaces: the LANANA-assigned namespace
(^[a-z0-9]+$); the LSB hierarchical and reserved namespaces
(^_?([a-z0-9_.]+-)+[a-z0-9]+$); and the Debian cron script namespace
(^[a-zA-Z0-9_-]+$).
당신이 크론 스크립트가 있다면 그래서 backup.sh, analyze-logs.pl에 cron.daily/디렉토리, 당신은 확장 이름을 제거하기 위해 최선을 것입니다.
답변
많은 환경에서 cron은을 사용하여 명령을 실행 sh하지만 많은 사람들이 사용한다고 가정합니다 bash.
실패한 명령에 대해이를 테스트하거나 수정하기위한 제안 :
-
명령을 실행하여
sh작동하는지 확인하십시오.sh -c "mycommand" -
bash 서브 쉘에 명령을 랩하여 bash에서 실행되도록하십시오.
bash -c "mybashcommand" -
crontab 상단에 쉘을 설정하여 bash에서 모든 명령을 실행하도록 cron에 지시하십시오.
SHELL=/bin/bash -
명령이 스크립트 인 경우 스크립트에 shebang이 포함되어 있는지 확인하십시오.
#!/bin/bash
답변
시간대에 문제가있었습니다. Cron은 새로운 설치 시간대로 실행되었습니다. 해결책은 cron을 다시 시작하는 것이 었습니다.
sudo service cron restart
답변
스크립트에는 절대 경로를 사용해야합니다.
예를 들어 다음 /bin/grep대신에 사용해야합니다 grep.
# m h dom mon dow command
0 0 * * * /bin/grep ERROR /home/adam/run.log &> /tmp/errors
대신에:
# m h dom mon dow command
0 0 * * * grep ERROR /home/adam/run.log &> /tmp/errors
쉘에서 실행될 때 동일한 명령이 작동하기 때문에 이것은 특히 까다 롭습니다. 그 이유는 사용자 cron와 동일한 PATH환경 변수 가 없기 때문입니다 .