Linux concept: cron

Bijna elke server draait werk waar niemand naar kijkt. Een backup om drie uur 's nachts, een certificaat dat twee keer per maand vernieuwd wordt, een cache die elk uur geleegd wordt. Het programma dat dat regelt doet hetzelfde werk sinds 1979, op vrijwel dezelfde manier, en het heet cron. Het is ook een van de makkelijkste onderdelen van een Linux-systeem om subtiel fout te doen, want een kapotte cron-taak en een werkende cron-taak zien er precies hetzelfde uit: stil.

2. Waar komt de naam vandaan?

De naam wordt algemeen herleid tot het Griekse chronos, tijd. De auteur van het oorspronkelijke programma heeft de afleiding nooit opgeschreven, dus zie dat als de aanvaarde verklaring en niet als een gedocumenteerd feit. Over de namen eromheen bestaat geen twijfel:

cron       the daemon that watches the clock
crontab    cron TABle - both the file and the command that edits it
cron.d     a drop-in directory of cron fragments
anacron    "anachronistic" cron: for machines that are not always on

De d aan het eind van crond op Red Hat-systemen is het gebruikelijke Unix-achtervoegsel voor een daemon, hetzelfde als in sshd, httpd en systemd. Debian en Ubuntu hebben hem gewoon weggelaten.

Een naamgevingsdetail doet er in de praktijk toe. Omdat zowel het bestand als het commando crontab heet, heeft het naslagwerk er twee verschillende pagina's voor, in twee verschillende secties:

$ man 1 crontab      # the command: -l, -e, -r
$ man 5 crontab      # the file format: the five fields

Bijna alles waar mensen het web voor afzoeken staat in crontab(5), en bijna niemand opent hem.

4. Eenvoudige toepassingen

4.1 De vijf velden

Een regel in een gebruikerscrontab bestaat uit vijf tijdvelden en daarna al het overige, en dat is het commando. Het commentaarblok dat Debian in /etc/crontab meelevert is er het beste schema van, en het staat al op je machine:

# .---------------- minute (0 - 59)
# |  .------------- hour (0 - 23)
# |  |  .---------- day of month (1 - 31)
# |  |  |  .------- month (1 - 12) OR jan,feb,mar,apr ...
# |  |  |  |  .---- day of week (0 - 6) (Sunday=0 or 7) OR sun,mon,tue,...
# |  |  |  |  |
# *  *  *  *  *  command to be executed

Lees een regel van rechts naar links en hij zegt zichzelf hardop. Deze draait elke dag om 03:30:

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

Een sterretje betekent "elke waarde van dit veld". De regel hierboven is dus: minuut 30, uur 3, elke dag van de maand, elke maand, elke dag van de week.

Zowel 0 als 7 betekent zondag in het veld voor de dag van de week, een historisch compromis tussen twee Unix-families die het oneens waren. Je mag ook Engelse afkortingen van drie letters schrijven, in willekeurige schrijfwijze:

0 4 * * 1        # Monday at 04:00
0 4 * * mon      # exactly the same
0 4 * * MON      # also the same, case does not matter

Namen mogen niet in reeksen of lijsten, dus mon-fri werkt wel maar een gemengde lijst van namen en getallen niet. Bij twijfel: gebruik getallen.

4.2 Je eigen crontab bewerken

Drie commando's dekken bijna alles:

Kijk eens naar -e en -r op een toetsenbord. Ze liggen naast elkaar, ze doen heel verschillende dingen, en er is geen ongedaan maken. Dit is een oprecht beroemde manier om een middag kwijt te raken. Twee gewoontes beschermen je:

$ crontab -l > ~/crontab.backup     # before you touch anything
$ crontab -i -r                     # -i asks for confirmation first

De laatste rij van de tabel is om een andere reden het kennen waard: crontab bestand betekent dat je taken in versiebeheer kunnen staan. Houd het echte bestand in een repository, en installeer het met een enkel commando:

$ crontab -n deploy.cron       # dry run: check the syntax, install nothing
$ crontab deploy.cron          # replace the live crontab with this file

De optie -n (kort voor no action, niets doen) is weinig bekend en is precies wat je wilt in een deployscript: hij ontleedt het bestand, meldt elke fout, en stopt zonder iets te wijzigen.

4.3 Waar de uitvoer heen gaat

Dit is het belangrijkste dat je over cron moet begrijpen, en het heeft niets met de planning te maken.

Alles wat een cron-taak afdrukt wordt behandeld als een foutmelding. Als een taak naar standaarduitvoer of standaardfout schrijft, mailt cron die tekst naar de eigenaar van de crontab. Drukt de taak niets af, dan zegt cron niets.

Op een desktop of een moderne server staat meestal geen mailsysteem geïnstalleerd, dus die mail gaat helemaal nergens heen. Je taak draait, drukt een fout af, en die fout wordt weggegooid. Daarom zijn kapotte cron-taken stil.

De oplossing is dat je zelf bepaalt waar de uitvoer heen gaat:

30 3 * * * /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1

Lees het staartje van die regel goed, want de volgorde doet ertoe:

In plaats daarvan 2>&1 >> bestand schrijven is een klassieke fout: dat richt de foutuitvoer op de terminal die cron je gaf (en dat is niets), en pas daarna wordt standaarduitvoer omgeleid. De omleiding moet eerst.

Je ziet ook op veel regels op internet > /dev/null 2>&1 staan. Dat legt de taak volledig het zwijgen op. Dat is de juiste keuze voor een taak die zelf logt, en de verkeerde keuze voor al het andere, want je gooit de enige waarschuwing weg die je zou krijgen.

4.4 De afkortingen

Vixie cron voegde acht bijzondere woorden toe die alle vijf de velden vervangen:

Ze lezen prettig, maar er zit een addertje onder het gras dat je moet kennen voordat je ze op een drukke server gebruikt: elke @daily-taak op de machine gaat af op precies 00:00, en elke @hourly-taak op precies minuut 0. Belasting spreiden is een goede reden om de velden uit te schrijven en een oneven minuut te kiezen.

@reboot heeft een waarschuwing in zijn eigen man-pagina. Hij draait als de cron-daemon start, en dat kan tijdens het opstarten voor het netwerk, de database of het bestandssysteem zijn dat je taak nodig heeft. Voor alles met echte afhankelijkheden is een systemd-unit het juiste gereedschap, en paragraaf 6.10 laat zien waarom.

6. Gevorderde toepassingen

6.1 De omgeving die een cron-taak echt krijgt

"Het werkt als ik het met de hand draai maar niet vanuit cron" is de meest gehoorde cron-klacht die er is, en de omgeving is bijna altijd de reden. In plaats van de bekende verhalen te herhalen, hier een meting. Deze crontab draaide op de machine waarop dit artikel geschreven is:

$ crontab -l
* * * * * /usr/bin/env > /tmp/cron-env.txt 2>&1

$ cat /tmp/cron-env.txt
HOME=/home/peter
LOGNAME=peter
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin
LANG=en_US.UTF-8
SHELL=/bin/sh
PWD=/home/peter

Zes variabelen. Dat is de hele wereld waarin je taak draait. Drie details uit die lijst doen er meer toe dan de rest.

Het PATH-advies dat je gelezen hebt klopt waarschijnlijk niet meer. Elke cron-handleiding zegt dat cron je een uitgeklede PATH van /usr/bin:/bin geeft. Dat is hier niet gebeurd, en de reden is te zien in de servicedefinitie:

$ systemctl cat cron.service | grep ExecStart
ExecStart=/usr/sbin/cron -f -P $EXTRA_OPTS

De optie -P betekent "stel PATH niet in voor kindprocessen, laat het erven". Op dit systeem komt de waarde dus uit /etc/environment via PAM, en is het een volkomen normaal systeem-PATH.

De bruikbare les overleeft de correctie, en is scherper dan het bekende verhaal: cron geeft je een systeem-PATH, nooit jouw PATH. Vergelijk de twee op dezelfde machine:

$ echo $PATH        # interactive shell
/bin:/home/peter/.local/bin:/usr/local/cuda/bin:/usr/local/sbin:/usr/local/bin:...
                    # plus a version manager, plus node_modules/.bin, plus more

Alles wat je .bashrc of .profile toevoegde is weg: ~/.local/bin, alles wat via nvm, rbenv of pyenv geïnstalleerd is, en elke map per project. Een taak die node of composer bij de kale naam aanroept werkt in je terminal en faalt onder cron, precies hierom.

SHELL is /bin/sh, niet bash. Op Debian en Ubuntu is /bin/sh dash, een kleinere, snellere en striktere shell. Alles wat bash-specifiek is faalt: [[ ... ]], arrays, source in plaats van ., ${var,,}. Het falen is vaak een enkele verwarrende regel in een log dat je niet leest.

Wat ontbreekt telt ook. Er is geen SSH_AUTH_SOCK, dus een taak die via SSH naar git pusht kan je agent niet gebruiken. Er is geen XDG_RUNTIME_DIR, dus systemctl --user en rootless containergereedschap gedragen zich vreemd. Er is geen DISPLAY, dus niets grafisch werkt.

Er zijn drie manieren om hiermee om te gaan, in oplopende mate van robuustheid:

# 1. Set what you need at the top of the crontab
SHELL=/bin/bash
PATH=/usr/local/bin:/usr/bin:/bin:/home/peter/.local/bin

# 2. Use absolute paths everywhere, always
30 3 * * * /usr/bin/php /var/www/site/cli/joomla.php scheduler:run --all

# 3. Best: call a script, and let the script set up its own world
30 3 * * * /usr/local/bin/nightly.sh

De derde is degene om naar te grijpen. Een crontabregel van een regel die een script aanroept houdt de planning en het werk gescheiden, zet de logica in versiebeheer, en laat je precies hetzelfde met de hand draaien terwijl je aan het testen bent.

6.2 De werkmap is niet waar je script staat

In de meting hierboven staat een regel die meer storingen veroorzaakt dan je zou denken:

PWD=/home/peter

cron start je taak in de thuismap van de gebruiker als wie hij draait. Niet in de map waar het script staat, en niet in de map waar jij toevallig stond toen je de crontabregel schreef. Voor taken in /etc/cron.d is het de thuismap van de gebruiker uit het zesde veld, wat voor www-data op Debian /var/www is. Voor de run-parts-mappen is het /, omdat /etc/crontab voor elk van die regels cd / && zegt.

Elk script dat een bestand ten opzichte van zichzelf zoekt breekt:

require 'config.php';          # PHP, resolved against the working directory
. ./settings.sh                # shell
source venv/bin/activate       # python virtualenv
cat ../data/input.csv          # anything at all

Alle vier werken als je het script vanuit zijn eigen map draait, en falen vanuit cron, met een foutmelding die naar een mail gaat die niemand leest. Er zijn twee goede oplossingen en een slechte:

# Acceptable: change directory in the crontab entry
0 3 * * * cd /var/www/site && /usr/bin/php cli/import.php

# Better: let the script find itself, so it works from anywhere
#!/bin/bash
cd "$(dirname "$0")" || exit 1

# Best: never use relative paths inside a scheduled script at all

De middelste is het waard om als gewoonte aan te nemen. Twee regels bovenaan elk script dat je plant halen deze hele categorie problemen weg, en het betekent ook dat je het script tijdens het testen vanuit je eigen thuismap kunt draaien.

6.3 Een taak opsporen die niet draait

"Mijn cron-taak werkt niet" zijn eigenlijk zes verschillende vragen, en die op volgorde beantwoorden vindt het probleem veel sneller dan gokken. Werk deze lijst af en stop bij de eerste stap die faalt.

1. Draait cron je crontab uberhaupt? Bewijs eerst dat het leidingwerk klopt. Installeer een taak die niet kan mislukken:

* * * * * /usr/bin/date >> /tmp/cron-test.log 2>&1

Wacht een minuut. Verschijnt /tmp/cron-test.log niet, dan zit het probleem niet in je script: het zit in de daemon, de crontab, of de toestemming om cron te gebruiken. Controleer systemctl is-active cron en paragraaf 6.6.

2. Heeft cron het geprobeerd? Het log vertelt je wat cron gestart heeft, en het toont het commando precies zoals cron het ontleed heeft. Hier zie je een procentteken opduiken als een afgekapt commando:

$ journalctl -t CRON --since '-10 min'

3. Werkt het commando met de hand? Draai de exacte tekst uit de crontab in je eigen shell. Faalt het hier, dan was cron nooit het probleem.

4. Werkt het als de juiste gebruiker? Een taak onder www-data heeft andere permissies, een andere thuismap, en mogelijk geen shell. Test als die gebruiker:

$ sudo -u www-data /usr/bin/php /var/www/site/cli/joomla.php scheduler:run --all

Deze ene stap vindt de meeste permissieproblemen meteen, en het is de stap die mensen overslaan.

5. Werkt het in de omgeving van cron? Hier komen de PATH- en shellverschillen uit 6.1 boven water. Kleed je omgeving uit en probeer opnieuw:

$ env -i /bin/sh -c '/usr/local/bin/job.sh'

Voor de exacte waarheid in plaats van een benadering: plan /usr/bin/env voor een minuut in en lees wat eruit komt, zoals in 6.1.

6. Wordt de uitvoer weggegooid? Draait de taak wel maar gebeurt er niets, voeg dan een omleiding toe en kijk wat hij zegt. Een omhulsel dat de omstandigheden naast de uitvoer vastlegt maakt van een onzichtbare storing een duidelijke:

#!/bin/bash
LOG=/var/log/myjob.log
{
    echo "===== $(date --iso-8601=seconds) ====="
    echo "user: $(id -un)  pwd: $(pwd)"
    echo "PATH=$PATH"
    /usr/bin/php /var/www/site/cli/import.php
    echo "exit: $?"
} >> "$LOG" 2>&1

Nog een controle geldt alleen voor de cron.daily-familie: staat het script in een van die mappen, draai er dan eerst run-parts --test op. Een probleem met de bestandsnaam laat elke stap hierboven er goed uitzien terwijl er nooit iets uitgevoerd wordt. Paragraaf 7.3 heeft de details.

6.4 Voorkomen dat taken overlappen

cron start vrolijk een taak terwijl de vorige nog bezig is. Een backup die normaal vier minuten duurt en elke vijf minuten gepland staat, draait op een slechte dag twee keer tegelijk. Twee kopieën die hetzelfde bestand schrijven is hoe backups corrupt raken.

cron heeft hier geen optie voor, maar flock lost het op met een enkel woord:

*/5 * * * * flock -n /tmp/backup.lock /usr/local/bin/backup.sh

De optie -n (kort voor nonblock) betekent: is het slot al bezet, geef dan meteen op in plaats van te wachten. De tweede run stopt stilletjes en de eerste gaat door. Twee varianten zijn het kennen waard:

Zet het slotbestand ergens dat blijft bestaan, zoals /var/lock, als de taak ertoe doet. Vergrendelen kost een regel, en het voorkomt een soort storing die achteraf oprecht lastig te onderzoeken is.

Overlap is niet de enige manier waarop een geplande taak de machine pijn doet. Een nachtelijk rapport dat elke kern volledig belast, of een backup die de schijf verzadigt, vertraagt de website die de reden is dat de server bestaat. Twee omhulsels kosten niets:

0 2 * * * nice -n 10 ionice -c 3 /usr/local/bin/report-generator

nice -n 10 verlaagt de CPU-prioriteit, zodat alles wat interactief is voorgaat. ionice -c 3 zet de taak in de idle-klasse voor schijftoegang, waar hij alleen aan de beurt komt als niets anders iets wil. Geen van beide maakt de taak trager op een rustige machine; allebei maken ze hem onzichtbaar op een drukke.

6.5 anacron, voor machines die niet altijd aan staan

cron heeft geen geheugen. Een laptop die om 06:25 dicht is draait de dagelijkse taken nooit, en haalt ze ook nooit in. anacron bestaat precies hiervoor, en zijn eigen man-pagina zegt het verschil onomwonden: hij gaat er niet van uit dat de machine doorlopend draait, en hij meet periodes in dagen in plaats van in kloktijden.

Zijn tabel heeft vier kolommen in plaats van vijf velden:

$ cat /etc/anacrontab
SHELL=/bin/sh
HOME=/root
LOGNAME=root

# period(days)  delay(min)  job-identifier   command
1               5           cron.daily       run-parts --report /etc/cron.daily
7               10          cron.weekly      run-parts --report /etc/cron.weekly
@monthly        15          cron.monthly     run-parts --report /etc/cron.monthly

Lees de eerste regel als: "draai dit hooguit een keer per dag; en als je hem start, wacht dan eerst vijf minuten". anacron legt na elke geslaagde run een tijdstempel per taaknaam vast, en vergelijkt bij de volgende start de datum. Was de laatste run gisteren of eerder, dan is de taak aan de beurt. De vertraging spreidt taken zodat een machine die wakker wordt niet alles tegelijk draait.

Alleen de datum wordt vergeleken, nooit het uur. anacron is het juiste gereedschap voor "ongeveer dagelijks" werk en het verkeerde voor alles dat op een bepaald tijdstip moet gebeuren.

Dit verklaart ook die test -x /usr/sbin/anacron ||-bewakingen in /etc/crontab. Is anacron geïnstalleerd, dan doet cron een stap terug uit de dagelijkse, wekelijkse en maandelijkse mappen en laat hij anacron de eigenaar zijn, zodat ze nooit allebei hetzelfde script draaien.

6.6 Wie cron mag gebruiken

Twee bestanden regelen de toegang, en de logica heeft een verrassing:

root mag altijd een crontab installeren, ongeacht beide bestanden. Op een gedeelde server of hostingserver is een /etc/cron.allow met alleen de accounts die het nodig hebben een goedkope en effectieve beperking, want het weigert iedereen standaard in plaats van dat jij ze allemaal moet opnoemen.

Een permissiedetail bijt mensen: allebei de bestanden moeten voor iedereen leesbaar zijn, of leesbaar voor de groep crontab. Zijn ze dat niet, dan weigert cron elke gebruiker de toegang totdat de permissies gerepareerd zijn.

6.7 Een geplande taak veilig houden

Een cron-taak is een onbeheerd commando dat als iemand draait, vaak als root, en dat eeuwig. Dat verdient dezelfde zorg als elke andere geprivilegieerde automatisering, en twee specifieke fouten komen keer op keer terug.

Een commandoregel is openbaar. Alles wat je in een crontab zet is tijdens het draaien zichtbaar in de procestabel, voor elke gebruiker op de machine:

$ ps -eo user,args | grep curl
root  curl -u admin:supersecret https://api.example.com/backup

Tenzij het systeem met hidepid is ingesteld, en dat is niet de standaard, kan elk lokaal account daarop wachten. Datzelfde geheim staat ook in het crontab-bestand, in je backups van dat bestand, en in elk log dat het commando vastlegt. Bewaar inloggegevens in een bestand dat de taak leest:

$ sudo install -o root -g root -m 600 /dev/null /etc/myapp/backup.env
$ sudoedit /etc/myapp/backup.env          # API_TOKEN=...

# and in the script, not in the crontab:
. /etc/myapp/backup.env
curl -H "Authorization: Bearer $API_TOKEN" https://api.example.com/backup

Een root-taak is niet veiliger dan het bestand dat hij draait. Deze regel ziet er prima uit:

0 3 * * * root /usr/local/sbin/backup.sh

Kan een willekeurige gebruiker zonder rechten in backup.sh schrijven, dan kan die gebruiker erin zetten wat hij wil en draait root dat om drie uur 's nachts. Dat is geen backupscript meer, dat is een root-shell met een tijdschakelaar. Hetzelfde geldt voor de map waarin het staat, want een bestand kunnen vervangen is net zo goed als het kunnen bewerken.

$ ls -ld /usr/local/sbin /usr/local/sbin/backup.sh
drwxr-xr-x 2 root root 4096 Aug 23 12:00 /usr/local/sbin
-rwxr-xr-x 1 root root  842 Aug 23 12:00 /usr/local/sbin/backup.sh

Beide horen eigendom van root te zijn en door niemand anders schrijfbaar. cron dwingt dit al af voor de crontab-bestanden zelf, en daarom worden /etc/cron.d-regels genegeerd als ze niet van root zijn of wel schrijfbaar voor groep of anderen, maar niets controleert het script aan de andere kant van de regel. Die controle is aan jou.

De derde regel heeft geen voorbeeld nodig: draai een taak niet als root omdat het makkelijker is. Het meeste geplande werk heeft een map en een database nodig, dus geef het een account met precies dat.

6.8 De planner van een webapplicatie aansturen

De meeste moderne webapplicaties hebben hun eigen takenplanner en verwachten een enkele cron-regel die hem aandrijft. Joomla is een goed voorbeeld, omdat het daar een consoleprogramma voor meelevert. De commandonamen komen rechtstreeks uit de geïnstalleerde broncode:

$ php /var/www/site/cli/joomla.php scheduler:list
$ php /var/www/site/cli/joomla.php scheduler:run --all
$ php /var/www/site/cli/joomla.php scheduler:run --id 3

De crontabregel die hem aanstuurt heeft drie dingen nodig die makkelijk fout gaan:

*/5 * * * * www-data /usr/bin/php /var/www/site/cli/joomla.php scheduler:run --all >> /var/log/joomla-cron.log 2>&1

• Draai als de gebruiker van de webserver. Draai je het als root, dan is elk cachebestand en elk log dat de applicatie schrijft eigendom van root, en kan de website er zelf niet meer in schrijven. Dit is een veelvoorkomende manier om een site te breken met een cron-taak die "werkt".
• Gebruik het absolute pad naar PHP. Er staat vaak meer dan een PHP op een server, en de CLI-versie is niet altijd degene die de webserver gebruikt. which php in jouw shell hoeft niet te zijn wat cron vindt.
• Log de uitvoer. De planner rapporteert wat hij gedraaid heeft. Zonder omleiding wordt dat rapport de leegte in gemaild.

Hetzelfde patroon geldt voor elke applicatie met een planner: draai als de gebruiker van de applicatie, met een absoluut pad naar de interpreter, en stuur de uitvoer naar een bestand. De applicatie bepaalt welke taken aan de beurt zijn; cron levert alleen een hartslag.

Het tweede punt verdient meer dan een regel, want "PHP is PHP" klopt niet. De PHP die cron draait is de CLI-versie, en op Debian en Ubuntu heeft die zijn eigen configuratie, volledig los van die van je website:

$ php --ini
Configuration File (php.ini) Path: /etc/php/8.3/cli
Loaded Configuration File:         /etc/php/8.3/cli/php.ini
Scan for additional .ini files in: /etc/php/8.3/cli/conf.d

Lees het pad. Dat deel cli is een mapnaam, en ernaast staat een map fpm met een andere php.ini en een andere set ingeschakelde extensies. Daar volgen vier dingen uit, en elk daarvan heeft weleens een supportmelding opgeleverd:

• Andere limieten. CLI komt meestal met memory_limit = -1 en geen maximale uitvoertijd, terwijl FPM echte limieten heeft. Een taak die in de browser sneuvelt kan vanuit cron probleemloos draaien, en een taak die je vanuit cron testte kan in de browser sneuvelen.
• Andere extensies. Een extensie die voor FPM aan staat, staat niet automatisch aan voor CLI. De taak faalt dan met "class not found" voor iets dat de website duidelijk wel heeft.
• Andere versies. Op een server met meerdere PHP-versies is /usr/bin/php welke versie ook het standaardalternatief is, en de site kan onder FPM een andere draaien.
• Alles anders, in een container. Draait de site in Docker, dan is de /usr/bin/php van de host helemaal niet de PHP van de site, en moet de cron-regel via de container.

Drie commando's beslechten het voordat je iets inplant:

$ /usr/bin/php -v         # which version cron will actually use
$ /usr/bin/php --ini      # which configuration it loads
$ /usr/bin/php -m         # which extensions are enabled for CLI

Noem op een server met meer dan een versie de versie expliciet in de crontab (/usr/bin/php8.3) in plaats van erop te vertrouwen dat de standaard bij de volgende upgrade blijft waar hij is.

6.9 Weten dat het echt gelukt is

cron start een commando en vergeet het. Hij kijkt nooit naar de afsluitcode, dus vanuit cron gezien zijn een backup die niets schreef en een backup die vijftig gigabyte schreef identieke gebeurtenissen. Wil je weten welke van de twee het was, dan moet de taak dat zelf zeggen.

Begin met het script eerlijk maken. Een shellscript geeft de status van zijn laatste commando terug, en dat is zelden wat je bedoelt:

#!/bin/bash
set -euo pipefail     # stop on the first error, and on a failure inside a pipe

Zonder pipefail meldt mysqldump ... | gzip > out.gz succes zodra gzip slaagt, en dat doet die zelfs als hij helemaal niets aangereikt krijgt.

Laat daarna een spoor achter dat iets van buiten kan controleren. Het patroon is een regel, en de && is de hele truc:

30 3 * * * /usr/local/bin/backup && touch /var/lib/myapp/backup.last-success

Het tijdstempel verschuift alleen als de taak geslaagd is. Nu wordt "heeft de backup vannacht gedraaid?" een vraag die iedereen kan beantwoorden, ook een monitoringsysteem dat geen idee heeft wat een backup is:

$ find /var/lib/myapp/backup.last-success -mmin +1500
/var/lib/myapp/backup.last-success        # printed = older than 25 hours = alert

Dit is sterker dan controleren of cron draait, en veel sterker dan controleren of de taak in het log staat, want het rapporteert over het werk in plaats van over de poging. Nuttige signalen, ongeveer op volgorde van hoeveel ze je vertellen:

Duw voor alles wat ertoe doet in plaats van te trekken: laat de taak bij succes een monitoringadres aanroepen, en laat die dienst alarm slaan als de aanroep uitblijft. Een taak die stil faalt en een taak die zes weken geleden verwijderd is zien er vanaf de server hetzelfde uit. Voor iets dat op een hartslag wacht zien ze er niet hetzelfde uit.

6.10 systemd-timers, het moderne alternatief

Op elke machine met systemd draait al een tweede planner, en een verrassende hoeveelheid werk waarvan je aanneemt dat cron het doet is er stilletjes naartoe verhuisd:

$ systemctl list-timers --all
NEXT                          LEFT       LAST                          UNIT
Sun 2026-08-23 15:39:00 CEST  4min 38s   Sun 2026-08-23 15:09:04 CEST  phpsessionclean.timer
Sun 2026-08-23 16:34:21 CEST  59min      Sun 2026-08-23 15:31:08 CEST  anacron.timer
Mon 2026-08-24 00:00:00 CEST  8h         Sun 2026-08-23 00:00:05 CEST  logrotate.timer
Mon 2026-08-24 01:47:50 CEST  10h        Sun 2026-08-23 05:28:44 CEST  man-db.timer

Een timer bestaat uit twee bestanden: een .timer die zegt wanneer, en een .service die zegt wat. Hier is degene die het opruimen van PHP-sessies uit paragraaf 5.2 overnam, en dat is de reden dat die cron-regel een systemd-test om zich heen heeft:

$ systemctl cat phpsessionclean.timer
[Unit]
Description=Clean PHP session files every 30 mins

[Timer]
OnCalendar=*-*-* *:09,39:00
Persistent=true

[Install]
WantedBy=timers.target

Die OnCalendar-regel is het directe equivalent van 09,39 * * * *. De schrijfwijze leest als jaar-maand-dag uur:minuut:seconde, en hij ondersteunt dezelfde lijsten en stappen als cron. Anders dan bij cron kun je vragen of je het goed hebt voordat je erop vertrouwt:

$ systemd-analyze calendar "*-*-* *:09,39:00"
Normalized form: *-*-* *:09,39:00
    Next elapse: Sun 2026-08-23 15:39:00 CEST
       (in UTC): Sun 2026-08-23 13:39:00 UTC
       From now: 2min 15s left

Er is geen cron-commando dat dit doet, en dat alleen al is een reden om naar een timer te grijpen als de planning ingewikkeld is.

De eerlijke samenvatting: voor "draai dit script elke nacht" is cron een regel en is er geen reden om iets te veranderen. Voor alles dat uitval moet overleven, op een andere service moet wachten, begrensd moet worden in verbruik, of getest moet worden voordat het live gaat, is een timer het betere gereedschap en verdient het extra bestand zich alleen al terug met de logging.

8. Best practices

• Zet het werk in een script, niet in de crontab. Een regel die /usr/local/bin/nightly.sh aanroept houdt de planning gescheiden van de logica, zet de logica in versiebeheer, laat je testen door het zelf te draaien, en betekent dat je nooit een procentteken hoeft te ontsnappen.
• Leid de uitvoer altijd om. Sluit elke regel af met >> /var/log/iets.log 2>&1, in die volgorde. Zonder dat is de enige melding van een storing een mail die waarschijnlijk nergens heen gaat.
• Gebruik overal absolute paden. Zowel voor de interpreter als voor het script. Het PATH van cron is een systeem-PATH, niet het jouwe, en niets wat je shell-profiel toevoegde is aanwezig.
• Test het commando in de omgeving van cron, niet in die van jou. env -i /bin/sh -c '/usr/local/bin/job.sh' brengt je dichtbij, en een tijdelijke * * * * *-regel die env draait geeft je de exacte waarheid.
• Maak een backup voordat je bewerkt. crontab -l > ~/crontab.backup kost een seconde, en -r ligt naast -e op het toetsenbord, zonder bevestiging en zonder ongedaan maken.
• Controleer de syntaxis voordat je installeert. crontab -n bestand ontleedt zonder iets te wijzigen, en dat is wat je in een deployscript wilt.
• Beperk nooit beide dagvelden op dezelfde regel. Ze worden gecombineerd met OF, niet met EN. Laat er een op * staan en zet de extra voorwaarde in het commando.
• Laat elk gepland script zijn eigen map opzoeken. cron start je in de thuismap van de gebruiker, niet naast het script. cd "$(dirname "$0")" bovenaan haalt een hele categorie "werkt met de hand, faalt vanuit cron" weg.
• Houd geheimen uit de crontab. Een commandoregel is via ps zichtbaar voor elke gebruiker op de machine. Zet inloggegevens in een bestand met modus 0600 en lees dat vanuit het script.
• Controleer wie het script van een root-taak mag schrijven. Kan een gebruiker zonder rechten het bewerken, of de map eromheen, dan is die gebruiker root. cron controleert de permissies van het crontab-bestand en verder niets.
• Roteer waar je naartoe logt. Een bestand waar elke vijf minuten iets bij komt vult uiteindelijk een schijf. Een blokje in /etc/logrotate.d, of een pipe naar logger, kost een minuut.
• Laat een succesmarkering achter, en waarschuw op de leeftijd ervan. taak && touch /var/lib/app/last-success maakt van "is het gelukt?" een vraag die een monitoringsysteem kan beantwoorden zonder iets van de taak te weten.
• Wees een goede buur op een drukke machine. nice -n 10 ionice -c 3 voor een zware taak zorgt dat hij niet concurreert met de website waarvoor de server bestaat.
• Zet flock -n voor alles wat lang kan duren. Dat ene woord voorkomt dat twee kopieën van een backup hetzelfde bestand schrijven.
• Geef de voorkeur aan /etc/cron.d voor servertaken. Gewone bestanden die configuratiebeheer kan uitrollen, met een expliciet gebruikersveld, en zonder punt in de bestandsnaam.
• Draai applicatietaken als de gebruiker van de applicatie. Een planner die als root draait laat bestanden van root achter en breekt de site die hij moest onderhouden.
• Monitor van buitenaf. Laat de taak zich bij een monitoringdienst melden als hij klaar is. De stilte van cron is identiek of de taak werkte, faalde, of sinds maart niet meer gedraaid heeft.

$ man 5 crontab           # the file format: fields, steps, the OR rule, the % rule
$ man 1 crontab           # the command: -l, -e, -r, -n, -i
$ man 8 cron              # the daemon: logging, DST, Debian specifics
$ man 8 anacron           # for machines that are not always on
$ man 8 run-parts         # the filename rules for cron.daily and friends
$ man 7 systemd.time      # OnCalendar syntax, if you move to timers

10. Samenvatting

cron is een klein, oud, buitengewoon betrouwbaar programma dat precies een ding doet, en de meeste problemen die mensen ermee hebben komen doordat ze meer verwachten.

• cron wordt een keer per minuut wakker, vergelijkt de klok met een lijst regels, en draait wat past. Hij heeft geen wachtrij, geen geheugen, en geen belangstelling voor de vraag of een taak gelukt is.
• Taken staan op drie soorten plaatsen: gebruikerscrontabs (vijf velden), /etc/crontab en /etc/cron.d (vijf velden plus een gebruiker), en de mappen in de stijl van cron.daily (scripts, geen planning).
• De vijf velden zijn minuut, uur, dag van de maand, maand, dag van de week. Zowel 0 als 7 betekent zondag.
• Reeksen, lijsten en stappen zijn vrij te combineren, maar een stap begint bovenaan zijn eigen veld opnieuw, dus */7 is geen gelijke tussenpoos.
• Zijn beide dagvelden beperkt, dan worden ze gecombineerd met OF. Beperk ze nooit allebei.
• Een niet-ontsnapt % beeindigt het commando en wordt standaardinvoer. Ontsnap hem als \%, of zet het commando in een script.
• Uitvoer wordt gemaild, en op de meeste servers gaat die mail nergens heen. Leid om met >> bestand 2>&1 of je hoort nooit dat een taak faalde.
• De omgeving bestaat uit zes variabelen. Het PATH is een systeem-PATH, niet het jouwe, en de shell is /bin/sh, geen bash.
• Taken starten in de thuismap van de gebruiker, niet naast het script, dus relatieve paden falen.
• In cron.daily en cron.d wordt een bestandsnaam met een punt stilzwijgend genegeerd. Controleer met run-parts --test.
• cron kijkt nooit naar de afsluitcode. Wil je weten dat een taak werkte, laat dan een succesmarkering achter en waarschuw op de leeftijd daarvan.
• Een crontab-commandoregel is via ps zichtbaar voor elke gebruiker, en een root-taak die een door gebruikers schrijfbaar script draait is een root-shell met een tijdschakelaar.
• cron gebruikt een tijdzone voor iedereen, en gaat verstandig om met zomertijd bij taken op een vast tijdstip.
• flock -n voorkomt dat runs overlappen. anacron dekt machines die uit staan.
• systemd-timers doen inhalen, afhankelijkheden, willekeurige vertraging, verbruikslimieten en logging in het journaal. Voor alles voorbij "draai dit elke nacht" zijn ze het betere gereedschap.

Dit is het spiekbriefje dat je wilt bewaren:

# .---------------- minute (0 - 59)
# |  .------------- hour (0 - 23)
# |  |  .---------- day of month (1 - 31)
# |  |  |  .------- month (1 - 12) or jan,feb,...
# |  |  |  |  .---- day of week (0 - 7) (0 and 7 are Sunday) or sun,mon,...
# *  *  *  *  *  command

crontab -l                     list your jobs
crontab -e                     edit them
crontab -l > backup.txt        back them up FIRST
crontab -n file                check syntax, install nothing
crontab file                   install from a file (version control)
crontab -i -r                  delete, with a confirmation prompt
crontab -u www-data -l         another user's jobs (root only)

*/5 * * * *                    every 5 minutes
15 */6 * * *                   00:15, 06:15, 12:15, 18:15
30 3 * * *                     03:30 every day
0 4 * * 1                      Mondays at 04:00
0 2 1 * *                      1st of the month at 02:00
@reboot                        when the cron daemon starts
@daily @weekly @monthly        midnight shorthands (all at 00:00)

... >> /var/log/job.log 2>&1   keep the output (order matters)
... > /dev/null 2>&1           throw it away on purpose
MAILTO=""                      no mail for any job in this file
flock -n /var/lock/j.lock ...  do not overlap with the previous run
nice -n 10 ionice -c 3 ...     stay out of the way on a busy machine
... 2>&1 | logger -t myjob     log to syslog instead of a file you must rotate
job && touch /var/lib/ok       success marker, for monitoring to check the age of
\%                             a literal percent sign

journalctl -t CRON             what cron started
run-parts --test /etc/cron.d   what would run from a directory
sudo -u www-data CMD           test as the user the job will run as
env -i /bin/sh -c 'CMD'        test in something close to cron's environment
php --ini                      which php.ini the CLI build loads
ps -eo user,args               proof that command lines are not private
systemctl edit cron.service    add -L 15 to log endings and failures
systemd-analyze calendar "..." test a systemd timer schedule

Een geplande taak is een van de weinige onderdelen van een server waar niemand naar kijkt tot de dag dat het ertoe doet. Wil je de backups, vernieuwingen en opruimtaken op je server zo ingericht hebben dat ze zichtbaar zijn als ze werken en luidruchtig als ze falen, in plaats van in beide gevallen stil, dan is dat precies het soort rustige werk waar ik graag bij help.