Monitorowanie crona na Linuksie

Klasyczny problem z cron : gdy job zawiedzie albo przestanie się uruchamiać, nikt nie dostaje powiadomienia. Lokalny mail crona ląduje w/var/mail którego nikt nie czyta. Efekt: backup po cichu zepsuty od 3 tygodni, odkryty w dniu, w którym naprawdę go potrzebujesz.

Dlaczego crony zawodzą po cichu

• Serwer się zrestartował, a crond nie wstał z powrotem.
• PATH crona różni się od interaktywnego shella → polecenie nie znalezione.
• Dysk jest pełny albo blokada (flock) wstrzymuje wykonanie.
• Skrypt się wysypuje, ale zwraca kod wyjścia 0, więc „wszystko gra”.

Szukasz samej linii crontaba — flagi curl, escapowanie %, ochrona przed nakładaniem się? Zobacz poradnik: cron co 5 minut.

Rozwiązanie: dead man's switch

Zamiast monitorować serwer, prosisz crona, żeby zgłosił, że się wykonał. Jeśli nie zgłosi się o zaplanowanej porze, to on sam jest problemem. Utwórz check w Cron-Ping, weź swój URL i dodaj curl :

# przed: nigdy nie wiesz, czy się wykonuje
0 2 * * * /opt/backup.sh

# po: ping tylko jeśli skrypt się powiedzie
0 2 * * * /opt/backup.sh && curl -fsS https://cron-ping.com/p/<token>

Odróżnij sukces od błędu

0 2 * * * /opt/backup.sh && curl -fsS https://cron-ping.com/p/<token> || curl -fsS https://cron-ping.com/p/<token>/fail

Jeśli backup.sh zawiedzie, wywołujemy /fail i dostajesz natychmiastowy alert, bez czekania na okres karencji.

Sprawdź, czy cron faktycznie działa

systemctl status cron      # Debian/Ubuntu
systemctl status crond     # RHEL/CentOS
grep CRON /var/log/syslog