Jedynym niezawodnym sposobem, jaki znalazłem, jest sprawdzenie dziennika.
cron
sprawdza /etc/crontab
co minutę i zapisuje komunikat wskazujący, że został ponownie załadowany lub że wykrył błąd.
Więc po edycji uruchom to:
sleep 60; grep crontab /var/log/syslog | tail
Lub, aby nie czekać pełną minutę, ale tylko do następnej minuty + 5 sekund:
sleep $(( 60 - $(date +%S) + 5 )) && grep cron /var/log/syslog | tail
Przykładowe dane wyjściowe z błędem:
Jan 9 19:10:57 r530a cron[107258]: Error: bad minute; while reading /etc/crontab
Jan 9 19:10:57 r530a cron[107258]: (*system*) ERROR (Syntax error, this crontab file will be ignored)
Dobra wydajność:
Jan 9 19:19:01 r530a cron[107258]: (*system*) RELOAD (/etc/crontab)
Tak jest w Debianie 8. W innych systemach cron może zalogować się do innego pliku.
(Myślałem, że mogę uniknąć polowania na odpowiedni plik dziennika za pomocą systemd's journalctl -u cron
, ale to nie pokazało mi tych wpisów w dzienniku i faktycznie z jakiegoś powodu przestałem rejestrować zdarzenia cron)