Cron-expressie vertalen:
wat doet deze regel?

Elke minuut van elk uur, elke dag — 1.440 keer per dag, 525.600 keer per jaar. Alle vijf velden zijn jokertekens, dus er is niets beperkt. Dat is de juiste planning voor een goedkope controleping en de verkeerde voor bijna al het andere. Overgeërfd voor een kostbaar script, is het de eerste regel om in twijfel te trekken.

Elke 5e waarde van dat veld, geteld vanaf het minimum. In het minutenveld vuurt */5 af op :00, :05, :10 … :55 — 12 keer per uur, precies op de klokwaarden. Het betekent niet „5 minuten na de vorige keer”: cron matcht op klokwaarden. Zo geeft */7 u :00, :07 … :56 en dan weer :00 — een gat van 4 minuten aan het begin van elk uur.

Elke dag om middernacht, servertijd — minuut 0 van uur 0, elke datum, elke maand, elke weekdag. Dit is precies de planning die @daily afkort. „Middernacht” is de middernacht van de server, en in de nacht van een DST-overgang kan een server op lokale tijd dit moment overslaan of dubbel uitvoeren.

Identiek. De bijnamen komen precies overeen: @hourly = 0 * * * *, @daily en @midnight = 0 0 * * *, @weekly = 0 0 * * 0, @monthly = 0 0 1 * *, @yearly = 0 0 1 1 *. De uitzondering is @reboot — dat is helemaal geen planning, maar vuurt af zodra de cron-daemon start. Deze vertaler schrijft de bijnamen altijd uit, zodat u steeds de vijf onderliggende velden ziet.

Omdat hij niet uit een crontab komt. Quartz (Jenkins, Spring), sommige cloud-schedulers en enkele cron-bibliotheken zetten een secondenveld vooraan, wat er zes maakt — of zeven met een jaar erachteraan. Een crontab installeert dit niet. Staat het secondenveld op 0, laat het dan weg: de overige vijf velden zijn meestal gewoon als POSIX te lezen. Staat er iets anders, dan vuurt de planning sneller dan eens per minuut af, en dat kan gewone cron helemaal niet uitdrukken.

Dat is Quartz-notatie voor „geen specifieke waarde”. Quartz eist dat precies een van de twee dagvelden buiten spel staat, en dat veld krijgt dan een vraagteken. POSIX-cron kent die regel niet en ook geen ? — een gewone * doet daar hetzelfde werk. Zijn beide dagvelden wel beperkt, dan draait cron op de vereniging van de twee. Plak een ? in een crontab en de regel wordt geweigerd.

Ja. Plak 30 3 * * * /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1 en de lezer pakt de vijf planningsvelden, vertaalt die, en benoemt de rest van de regel als het deel dat hij negeert. Hij herkent ook de opzet van /etc/crontab, waar een gebruikersnaam tussen de planning en het commando staat. Wat hij niet doet, is gokken bij een regel met zes velden: een secondenveld vooraan betekent Quartz, geen crontab, en dat is een andere taal.

Plak de expressie hierboven. Het resultaat toont de eerstvolgende tien uitvoeringen als concrete data, berekend door een echte parser in de tijdzone van uw browser. De crontab zelf draait op de klok van de server: staat die op UTC en u niet, dan verschuift de hele lijst met uw tijdsverschil. Of een uitvoering geslaagd is, meldt niets — cron logt alleen dat hij gestart is.