크론 오류는 어디에 기록됩니까?

cron작업을 잘못 설정 하면 자동으로 실패한 것으로 나타납니다. 무엇이 잘못되었는지 이해하려면 오류 로그를 어디에서 찾아야합니까?

다른 사람들이 지적했듯이, cron실행중인 프로그램의 출력 (출력이있는 경우) 을 이메일로 보내드립니다. 따라서 출력을 얻지 못하면 기본적으로 세 가지 가능성이 있습니다.

1. crond 프로그램을 실행하거나 이메일을 보내기 위해 쉘을 시작할 수조차 없습니다.
2. crond 출력물을 우편으로 보내지 못했거나 메일이 유실되었습니다.
3. 프로그램에서 출력을 생성하지 못했습니다 (오류 메시지 포함)

사례 1은 매우 드물지만 cron 로그에 무언가 기록되어 있어야합니다. Cron에는 자체 예약 된 syslog 기능이 있으므로 /etc/syslog.conf시설의 메시지 cron가 전송 되는 위치를 확인하려면 배포판의 동등한 파일을 살펴보십시오 . 인기있는 목적지를 포함 /var/log/cron, /var/log/messages하고 /var/log/syslog.

사례 2의 경우 mailer 데몬 로그를 검사해야합니다. Cron 데몬의 메시지는 대개 다음과 같습니다 root@yourhost. MAILTO=...crontab 파일 의 행을 사용하여 cron이 특정 주소로 이메일을 보내도록하여 메일러 데몬 로그를보다 쉽게 파악할 수 있습니다 . 예를 들어 :

MAILTO=my.offsite.email@example.org
00 15 * * *  echo "Just testing if crond sends email"

경우 3의 경우, 쉽게 확인할 수있는 다른 명령을 추가하여 프로그램이 실제로 실행되었는지 테스트 할 수 있습니다.

00 15 * * * /a/command; touch /tmp/a_command_has_run

crondmtime을보고 실제로 무언가를 실행 했는지 확인할 수 있습니다 /tmp/a_command_has_run.

작업 출력을 항상 명시 적으로 로그 파일로 보낼 수 있습니다.

0 8 * * * /usr/local/bin/myjob > /var/log/myjob.log 2>&1

crond iself는 작업에서 출력을 수신하지 않으므로 이전에 언급 한 메일 동작을 대체합니다. 이 동작을 유지하려면 tee (1)를 살펴보십시오.

메일이 보이지 않으면 해당 계정을 사용하여 모니터링하는 사람들에게 매우 성 가실 수있는 오류로 root @ yourcompany를 스팸으로 보내는 것일 수 있습니다. 대신 Syslog로 출력을 보내보십시오.

*/5 * * * * yourcronjob 2>&1 | /usr/bin/logger -t yourtag

그런 다음 cronjob이 실행될 때까지 기다렸다가 / var / log / messages (또는 일부 시스템의 경우 /var/log/user.log)에서 오류를 찾으십시오.

"yourcronjob : command not found"와 같이 1-2 줄 길이의 오류 메시지에 적합합니다. 또한 기존 syslog 인프라 (Logrotation, central syslogging, Splunk 등)를 사용합니다. 또한 이메일 스팸을 루트로 줄입니다.

cronjob이 수백 줄의 출력을 생성하는 경우 좋은 해결책이 아닐 수 있습니다.

기본 크론 구성은 프로그램 출력과 함께 메일을 보냅니다. 이것이 실패하면, 실패한 프로그램을 쉘 스크립트로 랩핑하여 프로그램이 실패하지 않도록하고 출력을 더 기록 할 수 있습니다.

이것은 일부 cron 구현에서 구성 가능한 설정입니다.

crond작업 실행에 실패하거나 작업이 0이 아닌 종료 코드를 리턴 할 때 이메일을 받아야 합니다. 입력 해보십시오.

$ mailx

명령 프롬프트에서.

mailx(1)대부분의 모든 유닉스 계열 시스템에서 기본 메일 읽기 프로그램입니다. 현대 표준에서는 매우 원시적이지만 항상 사용할 수 있다고 생각할 수 있습니다. 다른 더 나은 메일 에이전트를 사용할 수 있지만 사용중인 임의의 컴퓨터에 어떤 에이전트가 설치되어 있는지 알 수 없을 정도로 충분합니다.

시스템을 인터넷 이메일 서버로 구성하지 않은 경우이 메일 서브 시스템은 시스템 내에서만 사용됩니다. 기기의 다른 사용자와 이메일을주고받을 수는 있지만 전 세계로 이메일을 보내지 못할 수도 있으며 외부 세계의 이메일은 확실히 기기에 올 수 없습니다.

Cron은 기본 정보를로 기록 /var/log/messages하지만 호출 된 사용자에게 모든 프로그램 출력을 우송합니다.

몇 년 전에 동일한 문제가 발생 하여이 스레드를 우연히 발견했으며 최근에 위에서 언급 한 Ricardo의 솔루션에 대한 해결책을 발견했습니다. 이메일의 부족은 감지하기 어렵고 (앞서 언급했듯이) root @ yourcompany 이메일을 스팸으로 보내고 싶지는 않습니다. 관심이 있으시면 deadmanssnitch.com을 확인하십시오 . . 이 도구는 위에서 언급 한 경우를 해결하는 것 같습니다. 사용하기 매우 간단 해 보입니다. 도구가 제공하는 코드를 cronjob에 추가하면됩니다. 작업이 지정된 내부에서 실행되지 않으면 경고가 표시됩니다. 작업이 다시 시작되면 경고가 표시됩니다.

나는을 사용 vixie-cron하므로 이것이 모든 것에 적용되는지 모른다. 그러나 dead.letter작업의 모든 출력을 포함 하는 파일이 있습니다.

내 /root/폴더에는 crons.cron을 실행하여 crontab으로 설정했습니다 crontab /root/crons.cron. dead.letter에 만들어 질 /root/것입니다.

편집이 난 그냥 Google'd dead.letter, 그것은 배달 할 수없는 메일입니다. 그것은 분명히 cron과 관련이 없습니다. 메일이 제대로 설정되지 않은 경우 (나처럼) 파일이 있습니다.

초보자에게는 디버깅하기가 어려울 수 있습니다. 분과 시간 값을 서로 바꾸지 마십시오. 분이 먼저 온 다음 시간입니다. 각각에 대해 12 미만의 값을 제공하면 해당 값을 승인하지만 예상대로 작동하지 않거나 전혀 작동하지 않을 수 있습니다.