Linux taken plannen: cron versus systemd timer vergelijken

Taken plannen op Linux: cron versus systemd timer vergelijken

In Linux-systeembeheer is het wanneer een taak wordt uitgevoerd net zo belangrijk als wat er wordt uitgevoerd. De oudste vriend is cron, terwijl de meeste moderne distributies systemd timer gebruiken. In dit artikel vergelijken we beide en geven we aan in welke situaties welke tool het beste is.

1. Waarom cron en systemd timer vergelijken?

Veel Linux‑servers hebben de volgende eisen:

• Backups elke dag om 3:00 uur uitvoeren
• Een health‑check script elke 5 minuten draaien
• Logbestanden elke zondag comprimeren en opruimen
• Een init‑taak één keer, één minuut na het opstarten, uitvoeren

Traditioneel werden al deze taken met cron gedaan, maar nu gebruiken veel distributies systemd als init‑systeem, waardoor de timer unit een krachtige vervanger is.

2. Basisconcepten van cron

2.1 Wat is cron?

cron is een oude Unix/Linux scheduler. Het voert commando’s uit op een vastgestelde tijd of interval, en de configuratie wordt meestal beheerd via het crontab‑bestand.

2.2 Waar worden cron‑instellingen opgeslagen?

• Systeembreed: /etc/crontab, /etc/cron.d/
• Gebruikersspecifiek: via crontab -e

Bijvoorbeeld, een backup script elke dag om 3:00 uur:

0 3 * * * /usr/local/bin/backup.sh

De velden betekenen:

min  hour  day  month  weekday  command
0    3     *    *      *        /usr/local/bin/backup.sh

2.3 Voordelen van cron

• Oud en bewezen
• Consistent concept op vrijwel elk Unix‑/Linux‑systeem
• Eenvoudige syntaxis en veel voorbeelden
• Werkt ook op systemen zonder systemd

2.4 Beperkingen van cron

• Los van services, waardoor het moeilijk is te traceren welke service een taak start
• Log‑ en statuscontrole is omslachtig (syslog, e‑mail, etc.)
• Beperkte afhankelijkheids‑ en volgorde‑beheer
• Relatieve tijds‑scheduling (bijv. “5 minuten na opstart”) is onduidelijk

3. Basisconcepten van systemd timer

3.1 Wat is een systemd timer?

systemd timer is een timer unit van systemd. Het triggert een andere systemd service op basis van voorwaarden zoals tijd of tijd na opstart.

De structuur bestaat altijd uit een paar:

• myjob.service – definieert de werkelijke taak
• myjob.timer – bepaalt wanneer de taak wordt uitgevoerd

3.2 Service + timer voorbeeld

Een backup elke dag om 3:00 uur:

(1) Service unit: /etc/systemd/system/backup.service

[Unit]
Description=Daily backup job

[Service]
Type=oneshot
ExecStart=/usr/local/bin/backup.sh

(2) Timer unit: /etc/systemd/system/backup.timer

[Unit]
Description=Run daily backup at 3:00

[Timer]
OnCalendar=*-*-* 03:00:00
Persistent=true

[Install]
WantedBy=timers.target

Activeren:

sudo systemctl daemon-reload
sudo systemctl enable --now backup.timer

3.3 Voordelen van systemd timer

• Duidelijke koppeling met een service
• Log‑beheer via journalctl -u backup.service
• Flexibele trigger‑opties:
• OnCalendar= – cron‑achtige tijdsexpressie
• OnBootSec= – X seconden na opstart
• OnUnitActiveSec= / OnUnitInactiveSec= – relatieve tijd na laatste uitvoering
• Afhankelijkheids‑beheer: After=network-online.target etc.
• Volledig geïntegreerd met het systemd‑ecosysteem (systemctl list-timers, systemctl status)

3.4 Nadelen van systemd timer

• Hoger leercurve dan cron (service + timer bestanden)
• Afhankelijk van systemd (niet beschikbaar op oude of non‑systemd systemen)
• Voor een eenvoudige één‑regel taak kan het overkill lijken

4. Functie‑vergelijking

4.1 Overzichtstabel

5. Voorbeelden

5.1 Dagelijkse backup om 3:00 uur: cron vs timer

cron‑versie

0 3 * * * /usr/local/bin/backup.sh

systemd timer‑versie

# backup.service
[Unit]
Description=Daily backup job

[Service]
Type=oneshot
ExecStart=/usr/local/bin/backup.sh

# backup.timer
[Unit]
Description=Run daily backup at 3:00

[Timer]
OnCalendar=*-*-* 03:00:00
Persistent=true

[Install]
WantedBy=timers.target

5.2 Eén keer, 5 minuten na opstart

In cron vereist dit vaak een trick (bijv. @reboot + sleep).

systemd timer‑implementatie

# init-job.service
[Unit]
Description=Run custom init job after boot

[Service]
Type=oneshot
ExecStart=/usr/local/bin/init-job.sh

# init-job.timer
[Unit]
Description=Run init job 5 minutes after boot

[Timer]
OnBootSec=5min
AccuracySec=1min

[Install]
WantedBy=timers.target

Hierna wordt init-job.service één keer uitgevoerd, 5 minuten na het opstarten.

6. Welke kiezen?

6.1 Wanneer cron nog steeds prima is

• Veel bestaande cron‑taken die goed werken
• Kleine servers met slechts een paar eenvoudige taken
• Omgevingen zonder systemd (containers, BSD, zeer oude OS)

6.2 Wanneer systemd timer de voorkeur heeft

• De meeste services zijn al systemd‑gebaseerd
• Log‑ en statusbeheer op één plek
• Relatieve tijds‑scheduling nodig (bijv. “5 minuten na opstart”)
• Afhankelijkheids‑beheer (bijv. wacht op netwerk)
• Consistente observability in CI/CD of productie‑omgevingen

7. Tips voor migratie van cron naar systemd timer

1. Huidige cron‑taken inventariseren * crontab -l * /etc/crontab, /etc/cron.d/*
2. Taak splitsen in service + timer * Wat uitvoeren? → .service * Wanneer? → .timer
3. Tijd‑expressie converteren * 0 3 * * * → OnCalendar=*-*-* 03:00:00 * */5 * * * * → OnCalendar=*:0/5
4. Testen * systemctl start myjob.service * systemctl start myjob.timer → systemctl list-timers
5. Oude cron‑taken uitschakelen * Commentaar of verwijderen zodra de timer stabiel is

8. Conclusie: co‑existentie mogelijk

Kort samengevat:

• cron blijft een eenvoudige, draagbare scheduler
• systemd timer biedt een service‑gecentreerde, observabele en flexibele aanpak

Er is geen één juiste keuze. Voor nieuwe taken of taken die sterk gekoppeld zijn aan services, is systemd timer vaak de betere optie.