CRON testen op Ubuntu server

[X-DraGoN]

Opdracht is simpel: script moet uitgevoerd worden op elke eerste maandag van de maand

Na wat googlen vond ik onderstaande oplossing:

code:

0 3 */100,1-7 * MON /path/to/executable_script

Het heeft een paar maanden goed gelopen en nu ineens niet meer.

Nu wou ik dat testen, ik heb een apart VM opgezet en NTP uitgeschakeld.
Manueel de tijd ingesteld met het volgende commando:

code:

date -s "5 JUN 2023 2:55:00"

Daar heb ik dan een helloworld.sh script opgezet en proberen te laten uitvoeren:

code:

0 3 * * * /home/script.sh

en dat wordt dus niet uitgevoerd, weet iemand waarom?

[ge-flopt]

Hoe deze goed gelopen heeft weet ik niet:

At 03:00 on every 100th day-of-month and every day-of-month from 1 through 7 if it's on Monday.”

https://crontab.guru/#0_3_*/100,1-7_*_MON

[servies]

Volgens mij zou dit de entry moeten zijn:

0 3 1-7 * 1 /home/script.sh

om 3 uur in de nacht op de 1^e 7 dagen van de maand en dan op de 1^e dag van de week (maandag)
De voorwaarden zijn en/en...
Dus elke voorwaarde is een beperking meer.

[ Voor 23% gewijzigd door servies op 08-05-2023 15:46 ]

[ge-flopt]

Ik had je even wat verder moeten helpen, maar dat heeft @servies al gedaan. Als je naar de website gaat, dan kun je spelen met hoe je cron regel eruit moet zien en dus wanneer deze wordt uitgevoerd.

[luukvr]

/home is een beetje rare plek om bestanden in te zetten, staan normaal gesproken alleen user folders, maar als het er echt staat, ok. Je zou het resultaat van je CRON kunnen wegschrijven

code:

0 3 * * * /home/script.sh >> /home/result.log 2>&1

[X-DraGoN]

luukvr schreef op maandag 8 mei 2023 @ 16:09:
/home is een beetje rare plek om bestanden in te zetten, staan normaal gesproken alleen user folders, maar als het er echt staat, ok. Je zou het resultaat van je CRON kunnen wegschrijven

code:

0 3 * * * /home/script.sh >> /home/result.log 2>&1

Uiteraard staat het script daar niet, ik heb de rest even weg geknipt voor privacy doeleinden.
Maar wat met de 2de vraag voor te testen?

In die VM, als die ik notatie gebruik die servies aanhaalt (of eender welke andere die eerder wel werkte) waarom werkt die nu niet als ik de tijd handmatig op dat bepaalde uur zet?

Dit is trouwens ook 1 van de voorgesteld oplossingen:

code:

0 0 1-7 * * [ $(date +\%u) = 1 ] && /home/script.sh

Maar opnieuw, ik kan die niet testen, want cron wilt zelfs de meest simpele taken niet uitvoeren

[ Voor 13% gewijzigd door X-DraGoN op 08-05-2023 16:40 ]

[DataGhost]

Draait je cron-service wel? Doen andere cronjobs het? Wat is de installatiehistorie van je cron-service en wat zijn de wijzigingen tov de vorige versie die wel werkte? Staat er iets in je systeem-/cron-logs op het moment van uitvoeren of rond het moment van aanpassen van de crontab/cronjob? Is ergens een e-mail te vinden met output of job-status? Wordt het onder de juiste user uitgevoerd? Heb je de juiste syntax gebruikt (global- vs user-crontab)? Is de user wel toegestaan cronjobs uit te voeren (cron groep doorgaans)? Is het script executable? Werkt het script nog steeds als je deze gewoon uitvoert op de commandline? Heb je al eens geprobeerd deze cronjob aan te passen naar een ander known-good script, liefst uit een andere wel werkende cronjob? Staat je PATH goed of gebruik je overal absolute paden in alle aangeroepen sub-commando's en/of dependencies?

[deHakkelaar]

DataGhost schreef op maandag 8 mei 2023 @ 16:42:
Staat er iets in je systeem-/cron-logs op het moment van uitvoeren of rond het moment van aanpassen van de crontab/cronjob?

code:

sudo grep -i cron /var/log/syslog

Of via de journals ("2023-05-01" datum en "executable_script" aanpassen naar behoefte):

code:

journalctl --full --no-pager -S "2023-05-01" -g "executable_script" -u cron.service

EDIT:
@X-DraGoN , ow hoe maak je de cronjob aan?
Is dit via het crontab -e commando of heb je een config bestandje aangemaakt?
Daar zit namelijk verschil tussen.

[ Voor 15% gewijzigd door deHakkelaar op 08-05-2023 20:01 . Reden: datum aangepast ]

[aawe mwan]

Lees ook eens wat je te zien krijgt met man cron en man crontab . Ik zie bijvoorbeeld staan dat hij controleert wie de owner is van de crontab bestanden, als dat niet klopt dan doet hij het niet.

Verder is er verschil in de opmaak van crontab bestanden: in /etc/crontab en in de bestanden in /etc/cron.d moet op elke regel de naam staan van de user die het commando gaat uitvoeren (in jouw voorbeelden is dat niet te zien), maar in de tabellen die je invult met crontab -e en sudo crontab -e (dit zijn 2 verschillende crontabs) mag die er juist niet staan.

Maar de beste tip die je gekregen hebt is inderdaad om in /var/log/syslog te lezen wat er mis gaat.

[Hero of Time]

@deHakkelaar je kan ook 'journalctl --since today' doen voor logs van vandaag. Of --boot voor sinds boot.

@X-DraGoN als je gaat zoeken naar cron specifieke zaken, kan je ook journalctl --unit cron.service gebruiken om alleen zaken van Cron te tonen. Hier moet dan ook jouw entry staan, als die klopt en het script dat je wilt uitvoeren ook echt uitvoerbaar is (een chmod +x erop).

[deHakkelaar]

Hero of Time schreef op maandag 8 mei 2023 @ 19:21:
@deHakkelaar je kan ook 'journalctl --since today' doen voor logs van vandaag. Of --boot voor sinds boot.

Weet ik
--since = -S

"2023-05-07" was afgelopen Zondag, de dag waarop het script had moeten draaien.
EDIT: oops foutje, maandag had ie moeten draaien maar goed
Dan had ie moeten zijn:

code:

journalctl --full --no-pager -S "2023-05-01" -g "executable_script" -u cron.service

$ man journalctl
[..]
       -S, --since=, -U, --until=
           Start showing entries on or newer than the specified date, or
           on or older than the specified date, respectively. Date
           specifications should be of the format "2012-10-30 18:17:16".
           If the time part is omitted, "00:00:00" is assumed. If only
           the seconds component is omitted, ":00" is assumed. If the
           date component is omitted, the current day is assumed.
           Alternatively the strings "yesterday", "today", "tomorrow" are
           understood, which refer to 00:00:00 of the day before the
           current day, the current day, or the day after the current
           day, respectively.  "now" refers to the current time. Finally,
           relative times may be specified, prefixed with "-" or "+",
           referring to times before or after the current time,
           respectively. For complete time and date specification, see
           systemd.time(7). Note that --output=short-full prints
           timestamps that follow precisely this format.
[..]
       -b [[ID][±offset]|all], --boot[=[ID][±offset]|all]
           Show messages from a specific boot. This will add a match for
           "_BOOT_ID=".

           The argument may be empty, in which case logs for the current
           boot will be shown.

           If the boot ID is omitted, a positive offset will look up the
           boots starting from the beginning of the journal, and an
           equal-or-less-than zero offset will look up boots starting
           from the end of the journal. Thus, 1 means the first boot
           found in the journal in chronological order, 2 the second and
           so on; while -0 is the last boot, -1 the boot before last, and
           so on. An empty offset is equivalent to specifying -0, except
           when the current boot is not the last boot (e.g. because
           --directory was specified to look at logs from a different
           machine).

[ Voor 3% gewijzigd door deHakkelaar op 08-05-2023 19:31 ]

[MartinMeijerink]

X-DraGoN schreef op maandag 8 mei 2023 @ 16:36:
Maar opnieuw, ik kan die niet testen, want cron wilt zelfs de meest simpele taken niet uitvoeren

Waarom wil cron de meest simpele taken bij jou niet uitvoeren? Omdat je de tijd steeds terugzet!
Zie manpage:

Special considerations exist when the clock is changed by less than 3 hours, for example at the beginning and end of daylight savings time. If the time has moved forwards, those jobs which would have run in the time that was skipped will be run soon after the change. Conversely, if the time has moved backwards by less than 3 hours, those jobs that fall into the repeated time will not be re-run.

Dus zet niet meer de tijd terug, maar kijk eerst hoe laat het is, het is nu 20:21, dus nu zet je in de crontab:

code:

22 20 */100,8-14 * MON /path/to/executable_script

om het voor de test even op de tweede maandag (8-14) van de maand om 20:22 te laten uitvoeren.
Als het dan uiteindelijk werkt, maak je er weer de eerste maandag 3:00 van:

code:

0 3 */100,1-7 * MON /path/to/executable_script

[deHakkelaar]

aawe mwan schreef op maandag 8 mei 2023 @ 19:19:
Verder is er verschil in de opmaak van crontab bestanden: in /etc/crontab en in de bestanden in /etc/cron.d moet op elke regel de naam staan van de user die het commando gaat uitvoeren (in jouw voorbeelden is dat niet te zien), maar in de tabellen die je invult met crontab -e en sudo crontab -e (dit zijn 2 verschillende crontabs) mag die er juist niet staan.

Nog eentje waar je op moet letten, met crontab -e hoef je daarna niks meer te doen.
Met config bestandjes in de /etc/cron.d folder moet je cron daarvoor op de hoogte stellen dmv:

code:

sudo service cron reload

[deHakkelaar]

MartinMeijerink schreef op maandag 8 mei 2023 @ 20:21:
Dus zet niet meer de tijd terug, maar kijk eerst hoe laat het is, het is nu 20:21, dus nu zet je in de crontab:

code:

22 20 */100,8-14 * MON /path/to/executable_script

om het voor de test even op de tweede maandag (8-14) van de maand om 20:22 te laten uitvoeren.
Als het dan uiteindelijk werkt, maak je er weer de eerste maandag 3:00 van:

code:

0 3 */100,1-7 * MON /path/to/executable_script

@X-DraGoN , ter oa als aanvulling op boven, als je onder in een andere SSH sessie laat draaien, kun je live de journals volgen (-f = follow):

code:

journalctl --full -f -u cron.service

[Hero of Time]

deHakkelaar schreef op maandag 8 mei 2023 @ 20:22:
[...]

Nog eentje waar je op moet letten, met crontab -e hoef je daarna niks meer te doen.
Met config bestandjes in de /etc/cron.d folder moet je cron daarvoor op de hoogte stellen dmv:

code:

sudo service cron reload

Dat heb ik nog NOOIT hoeven doen en is ook helemaal niet nodig. Zie ook de manpage van cron(8):

Like /etc/crontab, the files in the /etc/cron.d directory are monitored for changes. In general, the system administrator should not use /etc/cron.d/, but use the standard system crontab /etc/crontab.

[deHakkelaar]

@Hero of Time , oops sorry, geen idee waar ik die gewoonte aan over heb gehouden.
Soms pik je gewoon verkeerde dingen op

[CyBeR]

Gebruik je je eigen crontab (crontab -e) of de system crontab (in /etc/cron.d)? In dat laatste geval moet er voor het commando nog de user staat waarmee het commando uitgevoerd moet worden.

[X-DraGoN]

MartinMeijerink schreef op maandag 8 mei 2023 @ 20:21:
[...]

Waarom wil cron de meest simpele taken bij jou niet uitvoeren? Omdat je de tijd steeds terugzet!
Zie manpage:

[...]

Ah kijk, dat wist ik niet.
Bedankt aan iedereen voor de informatie, ik ga er verder mee aan de slag om uit te zoeken waarom het niet werkte.
Ik post opnieuw als ik meer nieuws heb.

[X-DraGoN]

Na het testen lijkt het, met nieuwe inzichten van iedereen hierboven, tot de volgende oplossing te komen:

code:

0 3 1-7 * * [ $(date +\%u) = 1 ] && /path/to/script/execute.sh

Bedankt allemaal voor het meedenken.

[Hero of Time]

Er is een cron syntax mogelijk waardoor je geen date command test hoeft te doen. Zie https://blog.healthchecks...e-cron-job-the-funky-way/ bijvoorbeeld.

0 0 1-7 * */7

Here, the day of month is restricted to dates 1 to 7. Cron will interpret */7 in the day of week field as “every 7 days starting from 0 (Sunday)”, so, effectively, “Every Sunday”. Since the day of week field starts with *, cron will run the command on dates 1 to 7 which are also Sunday. In other words, this will match midnight of the first Sunday of every month.

In the above example, */7 is a trick to say “every Sunday” in a way that starts with the star. Unfortunately, this trick only works for Sunday. Can we make an expression that runs on, say, the first Monday of every month? Yes, we can!

0 0 */100,1-7 * MON

The day of month field here is */100,1-7, meaning “every 100 days starting from date 1, and also on dates 1-7”. Since there are no months with 100+ days, this again is a trick to say “on dates 1 to 7” but with a leading star. Because of the star, cron will run the command on dates 1 to 7 that are also Monday.

Deze had je eerder al, maar door je eerdere tijdmanipulatie kreeg je niet het resultaat wat je hoopte. Dit kan dus alsnog werken, of niet, afhankelijk van hoe je cron er mee om gaat uiteraard.

[ Voor 7% gewijzigd door Hero of Time op 09-05-2023 19:56 ]