| Harmonogram | Polecenie | Opis | Status | Akcje |
|---|---|---|---|---|
0 5 * * * |
/usr/local/bin/custom-backup.sh >> /var/log/arciveo-cron.log 2>&1 |
Nightly backup to remote storage | ||
*/15 * * * * |
/usr/local/bin/healthcheck.sh |
Ping external uptime monitor |
| Polecenie | |
|---|---|
30 1 * * * /usr/local/bin/clamav-scan.sh >> /var/log/arciveo-cron.log 2>&1 |
|
0 2 * * * /usr/bin/aide --config /etc/aide/aide.conf --check > /var/log/aide/aide.log 2>&1 |
|
@reboot chmod 755 /var/lib/aide |
|
0 3 * * * /usr/local/bin/lynis-scan.sh >> /var/log/arciveo-cron.log 2>&1 |
|
0 4 * * * /usr/local/bin/load-ipsum.sh >> /var/log/arciveo-cron.log 2>&1 |
|
@reboot sleep 60 && /usr/local/bin/load-ipsum.sh >> /var/log/arciveo-cron.log 2>&1 |
|
30 4 * * * /usr/local/bin/debsums-scan.sh >> /var/log/arciveo-cron.log 2>&1 |
|
0 6 * * * /usr/local/bin/logwatch_daily.sh >> /var/log/arciveo-cron.log 2>&1 |
|
0 8 * * * /usr/local/bin/daily-report-all.sh >> /var/log/arciveo-cron.log 2>&1 |
|
*/30 * * * * /usr/local/bin/smart-scan.sh >> /var/log/arciveo-cron.log 2>&1 |
|
0 * * * * /usr/bin/apt-get update -qq >/dev/null 2>&1 |
|
*/5 * * * * /usr/local/bin/collect-metrics-all.sh >> /var/log/arciveo-cron.log 2>&1 |
Cron nic o sobie nie mówi. Nie zgłasza, że zadanie się nie powiodło, nie pokazuje, kiedy wykonało się ostatnio, a błąd składni w pięciu polach harmonogramu nie ma gdzie się ujawnić. Formalnie cron wysyła list do lokalnego użytkownika, ale na serwerze, na którym nigdy nie skonfigurowano poczty wychodzącej, tej wiadomości nikt nie przeczyta. Zadanie może stać zepsute miesiącami, a zdradzają je dopiero skutki.
Ta strona pokazuje zadania dodane przez panel: harmonogram, polecenie, opis i stan, z możliwością włączenia, wyłączenia lub usunięcia bez otwierania terminala. Poniżej, jako osobna lista, znajdują się pozostałe wiersze root-crontab, czyli te, które wcześniej wpisali tam Państwo lub zainstalowany pakiet. Są tylko do odczytu: panel celowo nie edytuje tego, czego sam nie zapisał.
Trzy rzeczy warto tutaj sprawdzić. Zadanie, którego wyjście trafia do /dev/null 2>&1, milczy tak samo, gdy działa, jak wtedy, gdy jest zepsute. Polecenie zapisane samą nazwą zamiast pełną ścieżką zachowuje się inaczej niż w Państwa powłoce, bo cron ma własny, ubogi PATH. I sam harmonogram: zadanie kiedyś wyłączone na czas debugowania zwykle wyłączone zostaje. Po każdym podejrzeniu włamania cron również zasługuje na przejrzenie, bo zaczepienie się przez harmonogram jest łatwiejsze niż przez jednostkę startową, a taki wiersz wygląda całkiem zwyczajnie.