ubuntuusers.de

schneibva hat folgende Passage eingefügt:

1
2
3
4

339 	
	340 	Ein Fehler, der auch dazu führen kann, dass die Einträge in der '''crontab''' nicht ausgeührt werden, sind '''falsche Rechte''' für die crontab. Die Rechte sollten auf den 744 gesetzt werden.
	341 	
	342 	{{{sudo chmod 744 /etc/crontab …

Bei mir /etc/crontab mit den Rechten 644 versehen, und ich manipuliere nicht übermotiviert an Systemdateien rum. Das habe ich schon mal korrigiert.

Wieso sollte /etc/crontab auch ausführbar sein?

Fehler sind ja viele denkbar, aber wer würde die Rechte auf eigene Faust ändern (außer schneibva vielleicht)? Ich meine der ganze Absatz kann weg - im Support erinnere ich mich an keinen einzigen Fall, in dem dieses Problem auftrat.

user_unknown schrieb:

[…] Bei mir /etc/crontab mit den Rechten 644 versehen

Und das ist wohl auch richtig und sollte nicht geändert werden. Die Empfehlung 744 ist also falsch. Allerdings sind bei der crontab die Rechte sehr wohl funktionskritisch. Ich erinnere aber den exakten Kontext nicht und muss da erst einmal nachforschen.

Hallo,

Wieso sollte /etc/crontab auch ausführbar sein?

Genau, ein gesetztes Rechte für executable macht doch keine Sinn. Das ist doch eine Konfig-Datei, wie von Cron bzw. inzwischen von cron-systemd Konverter gelesen wird und dann werden zum gewünschten Zeitpunkt X die hinterlegten Befehle in der in der Crontab definierten Shell ausgeführt.

Gruß, noisefloor

Jetzt Baustelle.

Ich bin fertig mit der Überarbeitung. Aus meiner Sicht kann der Artikel zurück ins Wiki.

Hallo,

stimmt der Inhalt der 1. Hinweisbox in dieser Umfang noch? Zumindest unter Ubuntu 23.10 kümmert sich systemd um den ext-Dateisystemcheck, dafür gibt es Service- und Timer Units. Es gibt zwar eine Datei unter /etc/cron.d - aber der Cronjob wird soweit ich das sehe nur ausgeführt, wenn systemd nicht läuft (wie auch immer man diesen Zustand unter Ubuntu erreichen will).

Gruß, noisefloor

Die Geschwätzigkeit von Cron kann man einstellen. Dazu muss beim Aufruf des Programms die Option -L mit einer Zahl 0-15 angegeben werden.

Hier finde ich, würde für die bessere Verständlichkeit, der gesamte Befehl sehr helfen. (Zumindest mir, weil ich es z.Zt. nicht umsetzen könnte)

noisefloor schrieb:

[…] stimmt der Inhalt der 1. Hinweisbox in dieser Umfang noch?

Das ist eine gute Frage, von der ich nicht weiß, ob ich sie mit „ja“, „nein“ oder „vielleicht“ beantworten soll. Die Verhältnisse und Beziehungen zwischen Cron, Anacron und systemd sind leider unübersichtlich. Sie rufen sich gegenseitig auf und es ist sehr zeitaufwändig, genau zu eruieren, unter welchen Umständen der eine oder die andere welche Aufgabe konkret ausführt. Ich habe mich daher entschlossen, diesen für die Funktion von Cron/Anacron selbst nebensächlichen Aspekt schwammig mit „übernehmen bei Ubuntu wichtige Aufgaben“ zu umschreiben. Diese wichtigen Aufgaben sind mindestens, als Rückfalloptionen für andere Dienste zu dienen, vielleicht aber auch mehr.

Jedenfalls erscheint mir es nicht als völlig ungefährlich, in dieses System einzugreifen und daher halte ich diesen Hinweis für gerechtfertigt; eine Warnbox wäre aber übertrieben.

Zumindest unter Ubuntu 23.10 kümmert sich systemd um den ext-Dateisystemcheck, dafür gibt es Service- und Timer Units.

Interessant! Welche genau?

Es gibt zwar eine Datei unter /etc/cron.d - aber der Cronjob wird soweit ich das sehe nur ausgeführt, wenn systemd nicht läuft (wie auch immer man diesen Zustand unter Ubuntu erreichen will).

Konkret:

$ cat /etc/cron.d/e2scrub_all 
30 3 * * 0 root test -e /run/systemd/system || SERVICE_MODE=1 /usr/lib/x86_64-linux-gnu/e2fsprogs/e2scrub_all_cron
10 3 * * * root test -e /run/systemd/system || SERVICE_MODE=1 /sbin/e2scrub_all -A -r

Ich verstehe diese Cron-Jobs so:

• Wenn die Datei /run/systemd/system (ein Ordner, welcher von systemd angelegt wird, meines Wissens aber nichts darüber aussagt, ob Systemd aktuell läuft und schon gar nichts, ob Systemd sich um das Schrubben von Dateisystemen kümmert) nicht existiert, dann starte die zu den angegebenen Zeiten die Skripte zum Schrubben der Dateisysteme.

Das ist eine ziemlich seltsame Logik. Wenn man unterstellt, das hiermit „wenn systemd es nicht macht, dann mache ich (=Cron) es“ gemeint ist, dann ist es schlechte Programmierung, denn der Order existiert unabhängig davon, ob Systemd aktive Units für die Aufgabe hat oder nicht.

Vielleicht liegt es aber auch an meinem unvollständigen Verständnis der Weisheit dieser Jobs.

Berlin_1946 schrieb:

Die Geschwätzigkeit von Cron kann man einstellen. Dazu muss beim Aufruf des Programms die Option -L mit einer Zahl 0-15 angegeben werden.

Hier finde ich, würde für die bessere Verständlichkeit, der gesamte Befehl sehr helfen.

Es ist mehr als ein Befehl und es gibt mehrere Möglichkeiten. Es muss eine Systemdatei verändert werden, dies ist eine Standardaufgabe für den Administrator und das Arbeiten mit Root-Rechten; beide Artikel sind verlinkt.

Die Systemdatei kann z.B. die Systemd-Unit cron.service (wie im Artikel angegeben) sein, die man sich mit dem Befehl

systemctl cat cron.service 

anschauen kann. Wie man mit Systemd-Units arbeitet, ist an anderen Stellen im UbunutuUsers-de-Wiki beschrieben. Den Programmaufruf findet man in einer Systemd-Unit bei Schlüsselworten mit Exec (das verrät einem dieser Artikel nicht, darf aber als Grundlagenwissen vorausgesetzt werden, was man sich durchaus durch Lesen des guten UbuntuUsers-de-Wikis aneignen kann):

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

Mit Hilfe des im Artikel angegebenen Befehls

sudo systemctl edit cron.service 

ändert man diesen Programmaufruf ab wie im Artikel angegeben durch Hinzufügen einer Option zu:

ExecStart=/usr/sbin/cron -f -P $EXTRA_OPTS -L 15 

Was die Zahl 15 hier konkret bedeutet oder ob man vielleicht für die eigenen Bedürfnisse besser eine andere Zahl wählen sollte, kann man in der ebenfalls im Artikel angegebenen Manpage nachlesen.

Nichts, außer den konkreten Werten, die aber alle bereits im Artikel genannt werden, ist an dieser Prozedur spezifisch für Cron. Gehört also nicht in diesen Artikel.

Hallo kB,

danke für deine Nachhilfe. Ohne diese hätte ich es nicht verstanden.

Ich habe mal versucht, es so aufzuschreiben, wie ich es jetzt machen würde. Vllt kannst du ja mal prüfen, ob es so überarbeitet werden kann.

Die Geschwätzigkeit von Cron kann man einstellen. Dazu muss beim Aufruf des Programms mit dem Befehl

sudo systemctl edit cron.service

die Variablen EXTRA_OPTS mit der Option -L und einer Zahl 0-15 versehen werden.
Z.Bsp. so:

 $EXTRA_OPTS -L 15

oder die Variablen wird in der Datei /etc/default/cron, gemäß des vorgenannten Beispiels, definiert.
Zur Bedeutung der Zahlen 0-15 konsultiere die Manpage von Cron.

😎 Ist nur ein Vorschlag. 😇

kB schrieb:

noisefloor schrieb:

[…] stimmt der Inhalt der 1. Hinweisbox in dieser Umfang noch?

Das ist eine gute Frage, von der ich nicht weiß, ob ich sie mit „ja“, „nein“ oder „vielleicht“ beantworten soll. Die Verhältnisse und Beziehungen zwischen Cron, Anacron und systemd sind leider unübersichtlich. Sie rufen sich gegenseitig auf...

Nee. systemd hat die Hoheit. Beim Systemstart startet die Service Unit cron.service cron. Und anacron wird periodisch über die Timer Unit anacron.timer zu den Zeiten OnCalendar=*-*-* 07..23:30 aufgrufen.

Interessant! Welche genau?

Siehe /lib/systemd/system. Die Units haben alle ziemlich aussagekräftige Namen. Die Unit die apt update ausführt, läuft um 6 + 18 Uhr und die, die apt upgrade ausführt, um 18 -Uhr. Die Unit für das ext4 Dateisystem heißt e2scrub_all. Die Unit für die Logrotation heißt logrotate und läuft 1x täglich. Und so weiter.

Konkret:

$ cat /etc/cron.d/e2scrub_all 
30 3 * * 0 root test -e /run/systemd/system || SERVICE_MODE=1 /usr/lib/x86_64-linux-gnu/e2fsprogs/e2scrub_all_cron
10 3 * * * root test -e /run/systemd/system || SERVICE_MODE=1 /sbin/e2scrub_all -A -r

Ich verstehe diese Cron-Jobs so:

• Wenn die Datei /run/systemd/system (ein Ordner, welcher von systemd angelegt wird, meines Wissens aber nichts darüber aussagt, ob Systemd aktuell läuft und schon gar nichts, ob Systemd sich um das Schrubben von Dateisystemen kümmert) nicht existiert, dann starte die zu den angegebenen Zeiten die Skripte zum Schrubben der Dateisysteme.

Das ist eine ziemlich seltsame Logik. Wenn man unterstellt, das hiermit „wenn systemd es nicht macht, dann mache ich (=Cron) es“ gemeint ist, dann ist es schlechte Programmierung, denn der Order existiert unabhängig davon, ob Systemd aktive Units für die Aufgabe hat oder nicht.

Keine Ahnung, wo das her kommt, aber so wird es wohl sein. Es ist übrigens unter Raspberry Pi OS identisch (nur das es da ein paar weniger Cronjobs gibt), was die Vermutung nahelegt, dass das von Debian "geerbt" ist.

Die Units in /etc/cron.daily haben die selber Logik in den Skripten eingebaut. Die beginnen alle mit

# skip in favour of systemd timer
if [ -d /run/systemd/system ]; then
    exit 0
fi
...

Ich würde mal behaupten: cron läuft zwar, wird aber zur Systempflege überhaupt nicht mehr gebraucht. Das machen alles die systemd Units bzw. Timer. Ich würde auch behaupte, dass wenn man keine eigenen Cronjobs hat und eine Cronjobns hat, die Software $FOO nachträglich installiert hat, dass man die Units cron.service und anacron,timer deaktivieren kann, ohne das es nachteilig für das System ist.

noisefloor schrieb:

[…] systemd hat die Hoheit. Beim Systemstart startet die Service Unit cron.service cron. Und anacron wird periodisch über die Timer Unit anacron.timer zu den Zeiten OnCalendar=*-*-* 07..23:30 aufgrufen.

Ja. So habe ich es auch im Artikel beschrieben. Daraus folgt aber noch nicht, dass Cron/Anacron bei Ubuntu verzichtbar wären.

[…] Ich würde mal behaupten: cron läuft zwar, wird aber zur Systempflege überhaupt nicht mehr gebraucht.

Nein, das ist so nicht richtig:

Wenn man die Ausgaben von

systemctl list-timers --all | cat 

und

grep -v -e ^$ -e ^# -r /etc/cron{tab,.d/}
ls -l /etc/cron.{h,d,w,m}*ly/

vergleicht, finde ich Cron- bzw. Anacron-Jobs, welche nicht von Systemd-Timer-Units gesteuert werden.

Das machen alles die systemd Units bzw. Timer.

Sofern es solche gibt, ja. Ich habe mir die Mühe gemacht, auf einem 22.04-System den Start von Cron und Anacron üer die Systemd-Units zu deaktivieren und das System einige Tage zu beobachten. Vieles funktioniert, aber nicht alles. Ein Beispiel ist cron.daily/samba, welchen Systemd nicht ersetzt. Der gehört zwar nicht zum Standardumfang bei Installation des Systems, jedoch ist die Freigabe von Verzeichnissen über SMB (welches die (ggf. automatische) Installation des Samba-Servers erfordert) sehr verbreitet aktiviert. Ein weiteres Beispiel ist der stündliche Aufruf der Programme in /etc/cron.hourly/. Dieses Verzeichnis ist zwar standardmäßig leer, ermöglicht aber sehr einfach ohne Systemd regelmäßig wiederkehrend Jobs zu starten.

Ich würde auch behaupte, dass wenn man keine eigenen Cronjobs hat und eine Cronjobns hat, die Software $FOO nachträglich installiert hat, dass man die Units cron.service und anacron,timer deaktivieren kann, ohne das es nachteilig für das System ist.

Wie dargestellt, ist Deaktivierung nicht zu empfehlen. Bei Ubuntu übernimmt Cron/Anacron durchaus noch wichtige Pflegemaßnahmen am System.

Hallo,

Der gehört zwar nicht zum Standardumfang bei Installation des Systems, ...

Ok, guter Punkt. Könnte ja in der Tat sein, dass nachinstallierte Software noch nicht auf der Höhe der Zeit ist und nach wie Cron statt systemd nutzt.

Aber ich denke, wir sind uns einige, dass Cron nicht mehr so wichtig / relevant ist wie früber.

Gruß, noisefloor

Hallo,

vergleicht, finde ich Cron- bzw. Anacron-Jobs, welche nicht von Systemd-Timer-Units gesteuert werden.

Welche sind das denn bei dir? Sehe das bei 23.10 nicht, dass ein Cron-Job was macht, was systemd nicht macht.

ls -l /etc/cron.{h,d,w,m}*ly 

/etc/cron.daily:
insgesamt 24
-rwxr-xr-x 1 root root  311 Jul 13 15:05 0anacron
-rwxr-xr-x 1 root root  376 Okt  9 15:52 apport
-rwxr-xr-x 1 root root 1478 Aug  2 14:30 apt-compat
-rwxr-xr-x 1 root root  123 Jul 10 13:38 dpkg
-rwxr-xr-x 1 root root  377 Dez 14  2022 logrotate
-rwxr-xr-x 1 root root 1395 Jul 24 13:46 man-db

/etc/cron.hourly:
insgesamt 0

/etc/cron.monthly:
insgesamt 4
-rwxr-xr-x 1 root root 313 Jul 13 15:05 0anacron

/etc/cron.weekly:
insgesamt 8
-rwxr-xr-x 1 root root  312 Jul 13 15:05 0anacron
-rwxr-xr-x 1 root root 1055 Jul 24 13:46 man-db

vs.

systemctl list-timers --all 

NEXT                        LEFT           LAST                         PASSED              UNIT                           ACTIVATES                       
Fri 2023-12-01 14:43:59 CET 2min 10s left  -                            -                   update-notifier-download.timer update-notifier-download.service
Fri 2023-12-01 14:46:47 CET 4min 58s left  Sat 2023-10-21 15:40:08 CEST 1 month 10 days ago motd-news.timer                motd-news.service
Fri 2023-12-01 14:53:58 CET 12min left     -                            -                   systemd-tmpfiles-clean.timer   systemd-tmpfiles-clean.service
Fri 2023-12-01 15:09:21 CET 27min left     Sat 2023-10-21 15:40:08 CEST 1 month 10 days ago apt-daily-upgrade.timer        apt-daily-upgrade.service
Fri 2023-12-01 15:15:28 CET 33min left     Sat 2023-10-21 16:23:16 CEST 1 month 10 days ago fwupd-refresh.timer            fwupd-refresh.service
Fri 2023-12-01 16:05:36 CET 1h 23min left  Sat 2023-10-21 15:40:08 CEST 1 month 10 days ago fstrim.timer                   fstrim.service
Fri 2023-12-01 19:38:57 CET 4h 57min left  Sat 2023-10-21 15:40:08 CEST 1 month 10 days ago man-db.timer                   man-db.service
Fri 2023-12-01 23:10:03 CET 8h left        Sat 2023-10-21 15:40:08 CEST 1 month 10 days ago apt-daily.timer                apt-daily.service
Sat 2023-12-02 00:00:00 CET 9h left        Fri 2023-12-01 14:39:01 CET  2min 48s ago        dpkg-db-backup.timer           dpkg-db-backup.service
Sat 2023-12-02 00:00:00 CET 9h left        Fri 2023-12-01 14:39:01 CET  2min 48s ago        logrotate.timer                logrotate.service
Sun 2023-12-03 03:10:22 CET 1 day 12h left Fri 2023-12-01 14:39:23 CET  2min 26s ago        e2scrub_all.timer              e2scrub_all.service
Wed 2023-12-06 16:45:54 CET 5 days left    Sat 2023-10-21 15:40:12 CEST 1 month 10 days ago update-notifier-motd.timer     update-notifier-motd.service
-                           -              Fri 2023-12-01 14:39:45 CET  2min 3s ago         anacron.timer                  anacron.service
-                           -              -                            -                   apport-autoreport.timer        apport-autoreport.service
-                           -              -                            -                   snapd.snap-repair.timer        snapd.snap-repair.service
-                           -              -                            -                   ua-timer.timer                 ua-timer.service

16 timers listed.

Gruß, noisefloor

Ich gehe aus von den aktuellen LTS-Versionen 20.04 und 22.04. Bei 22.04 gibt es weniger Timer als von Dir für 23.10 gezeigt; das mag ein Indiz sein, dass Cron/Anacron mit neueren Versionen entlastet werden.

$ systemctl list-timers --all
NEXT                        LEFT           LAST                        PASSED              UNIT                         ACTIVATES                     
Sat 2023-12-02 09:19:17 CET 2min 19s left  n/a                         n/a                 systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service
Sat 2023-12-02 09:31:42 CET 14min left     Sat 2023-12-02 09:07:31 CET 9min ago            anacron.timer                anacron.service               
Sat 2023-12-02 09:31:57 CET 14min left     Fri 2023-12-01 10:33:29 CET 22h ago             apt-daily-upgrade.timer      apt-daily-upgrade.service     
Sat 2023-12-02 09:33:52 CET 16min left     Sat 2023-11-25 10:59:37 CET 6 days ago          apt-daily.timer              apt-daily.service             
Sat 2023-12-02 15:45:34 CET 6h left        Sat 2023-11-25 10:28:54 CET 6 days ago          fwupd-refresh.timer          fwupd-refresh.service         
Sat 2023-12-02 18:03:24 CET 8h left        Thu 2023-03-02 13:08:03 CET 9 months 0 days ago motd-news.timer              motd-news.service             
Sun 2023-12-03 00:00:00 CET 14h left       Sat 2023-12-02 08:57:54 CET 19min ago           logrotate.timer              logrotate.service             
Sun 2023-12-03 00:00:00 CET 14h left       Sat 2023-12-02 08:57:54 CET 19min ago           man-db.timer                 man-db.service                
Sun 2023-12-03 03:10:25 CET 17h left       Mon 2023-11-27 09:46:50 CET 4 days ago          e2scrub_all.timer            e2scrub_all.service           
Mon 2023-12-04 00:00:00 CET 1 day 14h left Mon 2023-11-27 09:45:49 CET 4 days ago          fstrim.timer                 fstrim.service                
n/a                         n/a            n/a                         n/a                 snapd.snap-repair.timer      snapd.snap-repair.service     
n/a                         n/a            n/a                         n/a                 ua-timer.timer               ua-timer.service              

Dagegen:

$ grep -v -e ^$ -e ^# -r /etc/cron{tab,.d/}
/etc/crontab:SHELL=/bin/sh
/etc/crontab:PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
/etc/crontab:17 *	* * *	root    cd / && run-parts --report /etc/cron.hourly
/etc/crontab:25 6	* * *	root	test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
/etc/crontab:47 6	* * 7	root	test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )
/etc/crontab:52 6	1 * *	root	test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )
/etc/cron.d/anacron:SHELL=/bin/sh
/etc/cron.d/anacron:PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
/etc/cron.d/anacron:30 7-23 * * *   root	[ -x /etc/init.d/anacron ] && if [ ! -d /run/systemd/system ]; then /usr/sbin/invoke-rc.d anacron start >/dev/null; fi
/etc/cron.d/popularity-contest:SHELL=/bin/sh
/etc/cron.d/popularity-contest:PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
/etc/cron.d/popularity-contest:54 17 * * *   root    test -x /etc/cron.daily/popularity-contest && /etc/cron.daily/popularity-contest --crond
/etc/cron.d/e2scrub_all:30 3 * * 0 root test -e /run/systemd/system || SERVICE_MODE=1 /usr/lib/x86_64-linux-gnu/e2fsprogs/e2scrub_all_cron
/etc/cron.d/e2scrub_all:10 3 * * * root test -e /run/systemd/system || SERVICE_MODE=1 /sbin/e2scrub_all -A -r

$ ls -Al /etc/cron.{h,d,w,m}*ly/
/etc/cron.daily/:
insgesamt 52
-rwxr-xr-x 1 root root  311 Jul 16  2019 0anacron
-rwxr-xr-x 1 root root  376 Dez  4  2019 [:apport:]
-rwxr-xr-x 1 root root 1478 Apr  9  2020 apt-compat
-rwxr-xr-x 1 root root  355 Dez 29  2017 bsdmainutils
-rwxr-xr-x 1 root root  384 Nov 19  2019 [:cracklib-runtime:]
-rwxr-xr-x 1 root root 1187 Sep  5  2019 dpkg
-rwxr-xr-x 1 root root  377 Jan 21  2019 logrotate
-rwxr-xr-x 1 root root 1123 Feb 25  2020 man-db
-rw-r--r-- 1 root root  102 Feb 13  2020 .placeholder
-rwxr-xr-x 1 root root 4574 Jul 18  2019 popularity-contest
-rwxr-xr-x 1 root root  383 Nov  8  2022 samba
-rwxr-xr-x 1 root root  214 Apr  2  2020 update-notifier-common

/etc/cron.hourly/:
insgesamt 4
-rw-r--r-- 1 root root 102 Feb 13  2020 .placeholder

/etc/cron.monthly/:
insgesamt 8
-rwxr-xr-x 1 root root 313 Jul 16  2019 0anacron
-rw-r--r-- 1 root root 102 Feb 13  2020 .placeholder

/etc/cron.weekly/:
insgesamt 20
-rwxr-xr-x 1 root root 312 Jul 16  2019 0anacron
-rwxr-xr-x 1 root root 730 Mär  8  2020 apt-xapian-index
-rwxr-xr-x 1 root root 813 Feb 25  2020 man-db
-rw-r--r-- 1 root root 102 Feb 13  2020 .placeholder
-rwxr-xr-x 1 root root 403 Jan 20  2023 update-notifier-common

Einige Jobs, die nach ihrem Namen nicht von Systemd erledigt werden, habe ich markiert. Umgekehrt gibt es natürlich auch etliches, was Systemd macht und wovon Cron/Anacrom gar keine Ahnung hat.