| Schema | Kommando | Beskrivning | Status | Åtgärder |
|---|---|---|---|---|
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 |
| Kommando | |
|---|---|
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 berättar ingenting om sig själv. Det rapporterar inte att ett jobb har misslyckats, visar inte när det senast kördes, och ett syntaxfel i schemats fem fält har ingenstans att märkas. Formellt skickar cron post till den lokala användaren, men på en server där utgående e-post aldrig ställts in läser ingen det meddelandet. Ett jobb kan stå trasigt i månader, och det är följderna som avslöjar det.
Sidan visar de jobb som lagts till via panelen: schema, kommando, beskrivning och status, med möjlighet att aktivera, inaktivera eller ta bort ett jobb utan att öppna en terminal. Under dem ligger, som en egen lista, resten av root-crontab: raderna som du eller ett installerat paket lade dit tidigare. De är skrivskyddade, eftersom panelen medvetet inte redigerar det den inte själv har skrivit.
Tre saker är värda att kontrollera här. Ett jobb vars utdata går till /dev/null 2>&1 tiger lika tyst när det fungerar som när det är trasigt. Ett kommando skrivet som ett kort namn i stället för en fullständig sökväg beter sig annorlunda än i ditt skal, för cron har en egen och mager PATH. Och schemat självt: ett jobb som en gång stängdes av för felsökning brukar förbli avstängt. Efter varje misstanke om intrång förtjänar cron också en genomläsning, eftersom det är enklare att fästa sig via schemaläggaren än via en startenhet, och raden ser fullkomligt vardaglig ut.