Migreer cronjobs op Linux in 9 stappen: crontab naar systemd

Gebruik crontab voor eenvoudige, persoonlijke taken die je snel wilt automatiseren. Voor productietaken met logging, retries en resource-limieten kies je systemd timers. Begin met crontab -e als je vandaag nog een taak wilt inplannen, of met systemctl --user als je serieuze automatisering met monitoring wilt opzetten.

Kort samengevat:

• Cron is geschikt voor eenvoudige persoonlijke taken, terwijl systemd timers beter passen bij complexe productie-omgevingen met logging en resourcebeheer.
• Het correct instellen van tijdvelden en het testen van scripts vóór implementatie zijn essentieel om onverwachte failures te voorkomen.
• Het beheer van crontab gebeurt veilig door back-ups te maken, permissies te controleren en enkel absolute paden te gebruiken in scripts.
• Bij belangrijke taken wordt aanbevolen om over te stappen op systemd timers, omdat zij betere logging, herstartopties en foutafhandeling bieden.
• Gebruik maken van monitoringdiensten zoals NLXS vermindert risico’s door automatische detectie van falende of gemiste jobs.

Inhoudsopgave

• Wat cron en crontab precies zijn
• Crontab-syntaxis en direct bruikbare voorbeelden
• Hoe je cronjobs aanmaakt, bekijkt en beheert
• Logging en foutafhandeling: maak cron-uitvoer zichtbaar
• Beveiligings- en hygiënepraktijken voor cronjobs
• Wanneer kies je systemd timers boven cron?
• Mijn advies: begin klein, migreer bewust
• Cronbeheer uitbesteden aan NLXS: minder gedoe, meer controle
• Bronnen

Wat cron en crontab precies zijn

Cron is de daemon die op de achtergrond draait en elke minuut controleert of er een taak moet worden uitgevoerd. Een crontab is het bestand waarin je die taken vastlegt: tijdstip plus commando. Op de meeste Linux-systemen bestaan er twee soorten crontabs, en het verschil is cruciaal voor hoe je cronjobs beheert.

• Per-gebruiker crontab: elke gebruiker heeft zijn eigen bestand, bewerkbaar met crontab -e, zonder gebruikersveld nodig.
• Systeemcrontab (/etc/crontab en /etc/cron.d/): bevat een extra kolom voor de gebruiker waaronder de taak draait, en wordt meestal door systeembeheerders gebruikt voor systeemwijde taken.

Bij het opstarten van een job geeft cron een beperkte omgeving mee. Variabelen zoals HOME, LOGNAME, SHELL en PATH worden automatisch ingesteld, maar vaak minimalistischer dan je interactieve shell. MAILTO bepaalt waar de uitvoer van een job naartoe gaat als er een mailsysteem actief is. Cron voert een taak uit zodra minuut, uur en maand overeenkomen én minstens één van de twee dagvelden matcht, zoals ook beschreven staat in de crontab(5) manualpagina van Debian. Dat laatste punt is een klassieke valkuil: veel mensen denken dat beide dagvelden gelijktijdig moeten kloppen.

Crontab-syntaxis en direct bruikbare voorbeelden

Een crontab-regel bestaat uit vijf tijdvelden gevolgd door het commando: minuut, uur, dag-van-maand, maand, dag-van-week, commando. Elk veld accepteert een vast getal, een sterretje voor “elke waarde”, een reeks (1-5), een lijst (1,15,30) of een interval (*/5). Het procentteken (%) in het commandoveld wordt door cron omgezet naar een nieuwe regel en gestuurd naar de standaardinvoer van je commando, zoals de crontab quick reference van AdminsChoice uitlegt. Wil je een letterlijk procentteken gebruiken, dan moet je het escapen met een backslash.

Voor herkenbare patronen bestaan handige afkortingen: @daily staat gelijk aan 0 0 * * *, @weekly aan 0 0 * * 0, en @reboot voert de taak precies één keer uit direct na het opstarten van het systeem. Deze shortcuts maken regels leesbaarder, vooral in scripts die andere teamleden ook moeten begrijpen.

Een paar voorbeelden die je direct kunt aanpassen:

1. Nachtelijke backup om 02:30: 30 2 * * * /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1
2. Healthcheck elke vijf minuten: */5 * * * * /usr/local/bin/healthcheck.sh
3. Wekelijkse logrotate-trigger op zondag: 15 3 * * 0 /usr/sbin/logrotate /etc/logrotate.conf
4. Opstartscript bij elke reboot: @reboot /usr/local/bin/init-services.sh

Test elke regel eerst handmatig in je terminal voordat je hem in de crontab zet. Een script dat perfect werkt als jij het start, kan om onverwachte redenen falen zodra cron het aanroept met een minimale omgeving.

Hoe je cronjobs aanmaakt, bekijkt en beheert

Het beheren van je crontab draait om een klein aantal commando’s, maar de details bepalen of je workflow veilig is.

• crontab -e opent je persoonlijke crontab in de editor die is opgegeven via de omgevingsvariabelen VISUAL of EDITOR. Staat geen van beide ingesteld, dan valt het systeem terug op een standaardeditor zoals vi of nano.
• crontab -l toont de huidige inhoud zonder iets te wijzigen, handig om snel te controleren wat er actief staat.
• crontab -r verwijdert de volledige crontab in één keer, zonder bevestiging. Gebruik daarom crontab -r -i, zodat je eerst een bevestigingsvraag krijgt.
• crontab -u gebruikersnaam -l laat een beheerder de crontab van een andere gebruiker bekijken, wat vaak nodig is bij troubleshooting.

Deze opties komen rechtstreeks uit de Man7, die ook vermelden dat sommige systemen automatisch backups van eerdere crontabs bewaren.

Pro-tip: Maak vóór elke grote wijziging een export met crontab -l > crontab_backup_$(date +%F).txt. Een verwijderde crontab is zonder backup niet meer terug te halen, en dat kost je precies op het verkeerde moment tijd.

Logging en foutafhandeling: maak cron-uitvoer zichtbaar

De meest onderschatte oorzaak van kapotte cronjobs is stille uitvoer. Zonder logging merk je pas na weken dat een taak allang niet meer draait.

• Stel MAILTO in als je systeem een werkende mailserver (MTA) heeft, maar vertrouw er niet blind op: veel servers hebben helemaal geen MTA geconfigureerd, waardoor mails in het niets verdwijnen.
• Redirect uitvoer altijd expliciet naar een logbestand, bijvoorbeeld met >> /var/log/mijnscript.log 2>&1, en koppel dat bestand aan logrotate zodat logs niet ongelimiteerd groeien.
• Op systemen met systemd is loggen via journald vaak betrouwbaarder dan handmatige bestandslogs, omdat je centraal kunt filteren met journalctl -u naam.service.

Deze aanpak sluit aan bij het inzicht dat de grootste bron van “cron-verrotting” onzichtbare foutmeldingen zijn, iets wat ook in migratiegidsen over systemd timers wordt benadrukt. Voor meldingen die je direct wilt zien verschijnen, is het combineren van redirects met een systeem voor automatische storingsmeldingen een logische volgende stap.

Beveiligings- en hygiënepraktijken voor cronjobs

Cron is een geliefd doelwit voor misbruik, precies omdat het overal draait en zelden wordt gecontroleerd. Een paar structurele maatregelen verkleinen dat risico aanzienlijk.

• Draai jobs altijd onder een beperkte gebruiker in plaats van root, ook als de taak “maar even snel” iets moet doen.
• Controleer dat /etc/crontab en bestanden in /etc/cron.d/ eigendom zijn van root met restrictieve permissies, en dat niemand anders erin kan schrijven.
• Gebruik altijd absolute paden in scripts en commando’s, stel een expliciete PATH in en zet een veilige umask aan het begin van elk script.
• Beperk wie crontabs mag aanmaken via cron.allow en cron.deny, zoals ook aanbevolen wordt in de SUSE-documentatie over het beperken van cron en at.
• Vermijd wereldschrijfbare scripts die door cron worden aangeroepen; dat is een van de meest voorkomende inbraakvectoren.

Beveiligingschecklists rond cron worden structureel onderschat: eenvoudige maatregelen zoals absolute paden, correcte permissies en dedicated gebruikers elimineren het merendeel van de risico’s, zoals de security-hardening gids van Systems Hardening laat zien. Wie dit als eenmalige actie ziet in plaats van als terugkerende controle, loopt het grootste risico.

Wanneer kies je systemd timers boven cron?

Cron blijft prima voor draagbare scripts, eenvoudige taken en systemen zonder systemd. Zodra je logging, herstartgedrag bij gemiste runs of resourcelimieten nodig hebt, is de balans duidelijk in het voordeel van systemd timers. Ze bieden geïntegreerde logging via journald, de optie Persistent=true om gemiste runs na een reboot alsnog uit te voeren, cgroup-gebaseerde resourcelimieten en OnFailure-hooks voor automatische meldingen bij falen, zoals uitgewerkt in de vergelijking tussen cron en systemd timers op Debian.

De migratie naar een timer volgt een vast patroon:

1. Observeer de huidige cronjob en noteer exact schema en commando.
2. Schrijf een .service-bestand met ExecStart en de juiste gebruiker.
3. Schrijf een bijpassend .timer-bestand met OnCalendar=.
4. Zet Persistent=true als gemiste runs later alsnog moeten draaien.
5. Voer systemctl daemon-reload uit na het aanmaken van de bestanden.
6. Enable de timer met systemctl enable --now naam.timer.
7. Test met systemctl start naam.service en controleer via journalctl.
8. Laat cron en de timer een periode naast elkaar draaien om gedrag te vergelijken.
9. Verwijder pas daarna de oude cronregel definitief.

Pro-tip: Vergeet stap acht niet over te slaan. Beide systemen tijdelijk actief laten voelt overbodig, maar voorkomt dat je een taak per ongeluk dubbel of helemaal niet meer laat draaien tijdens de overgang.

Mijn advies: begin klein, migreer bewust

Kies één kritische taak, niet tien. Test die grondig, migreer hem eventueel naar een systemd timer, en documenteer wat je hebt gedaan voordat je verder gaat. De meeste problemen met cronjobs ontstaan niet door foute syntaxis, maar door verwaarlozing: niemand kijkt nog naar logs, niemand weet meer waarom een regel bestaat. Wil je dat soort garanties zonder het zelf te blijven monitoren, dan is uitbesteden van remote serverbeheer op enig moment een logische stap.

— Ken

Cronbeheer uitbesteden aan NLXS: minder gedoe, meer controle

NLXS is het alternatief voor het zelf blijven monitoren van kritieke automatisering: waar een zelfbeheerde server pas een probleem toont ná een gemiste job, zet NLXS monitoring en logging vooraf goed op, zodat storingen zichtbaar zijn vóór ze schade doen.

Daarna richten we monitoring in, zodat een gemiste run of een falend script direct wordt gesignaleerd in plaats van pas na klachten van klanten. Dat past bij bedrijven die merken dat het zelf beheren van een server meer tijd kost dan het oplevert. Voor webshops die automatisering rond backups en onderhoud verder willen uitbouwen, biedt ook de gids over automatiseringsstrategieën voor e-commerce van onze partner Ecomtrada bruikbare aanvullende voorbeelden.

Wil je weten hoe jouw huidige server- of hostingomgeving ervoor staat? Bekijk onze pagina over WordPress webhosting bij NLXS of neem contact met ons op voor een vrijblijvende ICT-scan.

Bronnen

• crontab(5) — Debian manual pages
• crontab(1) — man7 Linux man-pages
• Crontab quick reference — AdminsChoice
• Linux Cron and at Job Security Hardening — Systems Hardening

Aanbevelingen

• Cloud migratie stappen: het stappenplan voor MKB
• Website migratie zonder downtime aanpakken
• Zakelijke website migreren zonder stress
• Website verhuizen zonder downtime doen zo