Gdzie są rejestrowane błędy CRON?

Jeśli cronniepoprawnie skonfiguruję zadania, wydają się cicho zawieść. Gdzie powinienem znaleźć dziennik błędów, aby zrozumieć, co poszło nie tak?

Jak zauważyli inni, cronwyśle ​​Ci pocztą e-mail dane wyjściowe dowolnego programu, który uruchamia (jeśli takie dane są dostępne). Jeśli więc nie uzyskasz żadnych wyników, istnieją zasadniczo trzy możliwości:

1. crond nie mógł nawet uruchomić powłoki do uruchamiania programu lub wysyłania wiadomości e-mail
2. crond wystąpiły problemy z wysyłaniem danych wyjściowych lub poczta została utracona.
3. program nie wygenerował żadnych danych wyjściowych (w tym komunikatów o błędach)

Przypadek 1. jest bardzo mało prawdopodobny, ale coś powinno być zapisane w logach cron. Cron ma własne zarezerwowane narzędzie syslog, więc powinieneś zajrzeć do /etc/syslog.conf(lub równoważnego pliku w twojej dystrybucji), aby zobaczyć, gdzie wysyłane cronsą wiadomości obiektu . Popularne kierunki obejmują /var/log/cron, /var/log/messagesi /var/log/syslog.

W przypadku 2. powinieneś sprawdzić dzienniki demona mailera: wiadomości od demona Crona zwykle pojawiają się jako od root@yourhost. Możesz użyć MAILTO=...linii w pliku crontab, aby cron wysłał e-mail na określony adres, co powinno ułatwić grepowanie dzienników demona mailera. Na przykład:

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

W przypadku 3. możesz sprawdzić, czy program został faktycznie uruchomiony, dodając inne polecenie, którego efekt możesz łatwo sprawdzić: na przykład,

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

więc możesz sprawdzić, czy crondrzeczywiście coś uruchomił, patrząc na mtime /tmp/a_command_has_run.

Zawsze możesz jawnie wysłać dane wyjściowe zadania do pliku dziennika:

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

Pamiętaj, że spowoduje to zastąpienie wcześniej wspomnianego zachowania poczty, ponieważ sam crond nie otrzyma żadnych danych wyjściowych z zadania. Jeśli chcesz zachować to zachowanie, powinieneś zajrzeć do tee (1).

Jeśli nie widzisz wiadomości e-mail, możesz spamować root @ twoja firma z błędami, które mogą być dość denerwujące dla osób, które używają tego konta do monitorowania. Zamiast tego spróbuj wysłać dane wyjściowe do Syslog:

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

Następnie poczekaj na uruchomienie cronjob i poszukaj błędu w / var / log / messages (lub /var/log/user.log w niektórych systemach).

Działa to doskonale w przypadku komunikatów o błędach, które mają tylko 1-2 wiersze, takich jak „twoja robota: nie znaleziono polecenia”. Wykorzystuje również istniejącą infrastrukturę syslog (Logrotation, centralne syslogging, Splunk, itp.) Zmniejsza również spam w poczcie e-mail.

To może nie być dobre rozwiązanie, jeśli twój cronjob generuje setki linii wyjścia.

Domyślna konfiguracja crona wyśle ​​ci wiadomość z wyjściem twojego programu. Jeśli to się nie powiedzie, możesz spróbować owinąć wadliwy program w skrypt powłoki, który zapewni, że program się nie zawiedzie, i możesz dalej rejestrować dane wyjściowe.

Jest to konfigurowalne ustawienie w niektórych implementacjach crona.

Powinieneś otrzymać wiadomość e-mail od crondmomentu, gdy zadanie nie uruchomi się lub gdy zadanie zwróci niezerowy kod wyjścia. Spróbuj wpisać:

$ mailx

w wierszu polecenia.

mailx(1)to podstawowy program do czytania poczty w większości systemów uniksowych. Jest to bardzo prymitywne, jak na współczesne standardy, ale możesz liczyć na to, że zawsze będzie dostępny. Mogą być dostępne inne, lepsze agenty pocztowe, ale jest ich wystarczająco dużo, abyś nigdy nie wiedział, który z nich jest zainstalowany na jakimś losowym komputerze, którego używasz.

Należy pamiętać, że o ile nie skonfigurowano systemu jako internetowego serwera poczty e-mail, ten podsystem poczty jest używany tylko w urządzeniu. Możesz wysyłać i odbierać wiadomości e-mail od innych użytkowników urządzenia, ale możesz nie być w stanie wysyłać wiadomości e-mail na cały świat, a wiadomości e-mail ze świata zewnętrznego na pewno nie będą mogły dotrzeć do Twojego komputera.

Cron zapisuje podstawowe informacje /var/log/messages, ale wysyła pocztą e-mail wszelkie dane wyjściowe programu do wywołującego użytkownika.

Kilka lat temu natknąłem się na ten wątek, doświadczając tych samych problemów i niedawno znalazłem rozwiązanie wyżej wymienionych przypadków przez Ricardo. Brak wiadomości e-mail jest trudny do wykrycia (jak wspomniałeś) i na pewno nie chcesz spamować swojego roota @ e-maila firmowego. Jeśli jesteś zainteresowany, sprawdź deadmanssnitch.com. . To narzędzie wydaje się rozwiązać wyżej wymienione przypadki. Wydaje się dość prosty w użyciu - wystarczy dodać trochę kodu, który narzędzie daje ci do pracy z cronjob. Jeśli Twoje zadanie nie uruchomi się w określonym wewnętrznym trybie, zostaniesz o tym powiadomiony. Jeśli Twoje zadanie zacznie działać ponownie, zostaniesz również powiadomiony.

Używam vixie-cron, więc nie wiem, czy to dotyczy wszystkiego. Ale mam dead.letterplik, który zawiera wszystkie dane wyjściowe zadania.

W moim /root/folderze mam, crons.cronktóry ustawiłem jako mój crontab, uruchamiając crontab /root/crons.cron. dead.letterzostaną również utworzone w /root/.

Edytuj Po prostu Google dead.letter, a jest to poczta niedostarczalna. Najwyraźniej nie ma to nic wspólnego z cronem. Jeśli nie masz poprawnie skonfigurowanej poczty (jak ja), będziesz mieć plik.

Dla początkujących może to być problem z debugowaniem. Pamiętaj, aby nie zamieniać wartości minut i godzin. Najpierw przychodzi minuta, potem godzina. Jeśli podasz wartości mniejsze niż 12 dla każdej z nich, zaakceptuje je, ale może nie działać zgodnie z oczekiwaniami lub wcale.