Odpowiedzi:
Sprawdź, czy programy uruchamiane z cronem mają własne pliki dziennika. Jeśli nie zapisują swoich danych wyjściowych na standardowych wyjściach, możesz przekierować je do plików lub przesłać je pocztą. Wewnątrz crontabs działa standardowe przekierowanie powłoki .
Np. Aby przekierować wyjście błędu some_job.shdo some_job.erri odrzucić standardowe wyjście (tj. Wysłać je do /dev/null) dodaj następujące przekierowanie do twojego crontab
33 3 * * * /path/to/some_job.sh 1> /dev/null 2> /other/path/to/some_job.err
lub zamiast tego wyślij go tobie (jeśli mailjest dostępny)
33 3 * * * /path/to/some_job.sh 1> /dev/null 2>&1 | mail -s "cron output" you@example.org
/dev/null?
some_job.shwejścia na /dev/nulli tylko po jego standardowym ustawieniu na standardowe (które teraz nie zawiera już niczego). W ten sposób tylko jego stderr kończy się na stdout i jest przekazywany do mail.
Większość demonów cron na platformach, z którymi współpracowałem, automatycznie wysyła pocztą e-mail stdout / stderr zadań cron użytkownika do użytkownika, z którego pochodzi crontab. Zapomniałem, co dzieje się z całym systemem (niespecyficzne dla użytkownika zadania cron z / etc / crontab). Chodzi o to, że ludzie nie zawsze konfigurują demona mailera (to znaczy Mail Transfer Agent (MTA), takiego jak sendmail, qmail lub postfix) w większości systemów operacyjnych typu Unix. Tak więc e-maile wyjściowe zadania cron po prostu giną w lokalnym folderze buforowania poczty, nawet jeśli dotrą tak daleko. Tak więc jedną z odpowiedzi może być po prostu odpalenie demona mailera i być może upewnij się, że masz plik ~ / .forward, aby przekazywać lokalną pocztę na twoje „prawdziwe” konto e-mail.
Jeśli chcesz, aby twoje zadania zapisywały do określonych plików dziennika, możesz użyć standardowego przekierowania danych wyjściowych, takiego jak sugerowane @honk, lub zakładając, że twoje zadanie cron jest skryptem powłoki, możesz mieć program do rejestrowania wywołań skryptów (1) lub syslog (1) lub jakiekolwiek inne narzędzie wiersza polecenia, jakie Twój system operacyjny udostępnia do wysyłania dowolnych wiadomości do syslog. Następnie możesz użyć wbudowanych metod systemu operacyjnego do skonfigurowania, które rodzaje wiadomości są rejestrowane, np. Przez edycję /etc/syslog.conf.
Większość moich zadań cron wywołuje skrypty bash, które napisałem specjalnie w celu uruchomienia przez crona z konkretnego powodu. W tych, szczególnie gdy początkowo je piszę i debuguję, lubię używać „set -vx” basha, aby nie rozszerzana i rozszerzona forma każdej linii skryptu powłoki była zapisywana na standardowe wyjście, zanim zostanie wykonana. Zauważ, że skrypty powłoki uruchomione z crona są uważane za powłoki niezalogowane, nieinteraktywne, więc standardowe skrypty startowe powłoki, takie jak .bashrc i .profile, nie są uruchamiane. Jeśli używasz bash i chcesz, aby bash uruchomił skrypt startowy, musisz zdefiniować zmienną środowiskową „BASH_ENV = / path / to / my / startup / script” w swoim crontabie przed linią, w której definiujesz zadanie.
mailpolecenia, aby odczytać wiadomości z wiersza poleceń. Lub spójrz na /var/spool/mail. Ale jeśli zainstalowałeś Postfix lub inny program pocztowy niż standardowy sendmail, potrzebny jest inny sposób czytania wiadomości.
mail -s "cron output" test@example.comdziała dobrze: /
less $MAILjeśli chcesz zobaczyć dane wyjściowe crona dla bieżącego użytkownika lub less /var/spool/mail/rootjeśli chcesz zobaczyć dane wyjściowe crona dla poleceń działających jako root.
Najprostszym sposobem jest przechwycenie błędów drukowania i zapisanie ich w pliku. Mam cronjob, który wywołuje linię poleceń php, jak to:
1 0 * * * php /pathOfMyApp/index.php nazwa kontrolera nazwa funkcji> / pathOfMyApp / log / myErrorLog 2> & 1
Część przed „>” to moja praca z cronem, a po „>” to przechwytywanie i zapisywanie w pliku znajdującym się w folderze dziennika w katalogu głównym mojego projektu, ale może być w wybranym miejscu. Zachowaj czujność: za każdym razem, gdy zadzwoni kronika, nadpisze ostatni dziennik. Możesz użyć „>>”, aby zapisać na końcu istniejącego pliku lub wyszukać polecenie terminalu „cat”.
Jeśli twój crontab używa „curl” lub „wget” i odwołuje się do linku, możesz wyszukać w / var / log / httpd / appName log-dostępu, jeśli cron zwraca 500 lub 400, to musi być coś nie tak.
Nareszcie możesz także sprawdzić / var / log / messages.
Myślę, że przekierowanie w pliku cron może nie być najlepszą opcją w tym przypadku.
Często chcesz, aby mowa dotycząca rejestrowania znajdowała się w tym samym miejscu co skrypt zadania cron. W takim przypadku proponuję następujące:
#!/bin/bash
exec &>> capture-log.txt
echo "Running cron-job foo at $(date)"
...
<rest of script>
To dołącza dane wyjściowe z zadania cron do pliku capture-log.txt.
Wolę otrzymywać raporty e-mail o zadaniach crona. Po prostu włóż
MAILTO=yourmail@domain.com
do crontab, a otrzymasz wiadomość e-mail. Oczywiście musisz skonfigurować e-mail dla swojego konta.