[gelöst] cron führt systemctl suspend nicht aus

[eikko]

Hallo zusammen,

seit dem Update auf Debian 11 wird der cronjob

55 23 * * * /usr/bin/systemctl suspend >> /tmp/00log 2>&1

nicht mehr ausgeführt.

Besser gesagt, der Aufruf wird zwar durchgeführt, aber das System geht nicht in den Ruhemodus.
Wenn ich das per Hand starte funktioniert es problemlos.

Hat jemand einen Idee?

Grüße eikko

[eikko]

Keiner der das Problem schon mal hatte?

eikko

[Draal]

Ich würde es mal ohne Pfad probieren, also:

Code: Alles auswählen

55 23 * * * systemctl suspend >> /tmp/00log 2>&1

[mat6937]

Ich würde es mal ohne Pfad probieren, also:

Code: Alles auswählen

55 23 * * * systemctl suspend >> /tmp/00log 2>&1

Dann hätte der TE aber in der log-Datei so einen ähnlichen Hinweis:

Code: Alles auswählen

/usr/bin/systemctl: No such file or directory

sehen müssen, oder?
@TE: Wie ist die Ausgabe von:

Code: Alles auswählen

which systemctl

?

[JTH]

55 23 * * * /usr/bin/systemctl suspend >> /tmp/00log 2>&1

Ihr beiden dürftet auf dem richtigen Pfad sein. systemctl liegt in /bin, nicht in /usr/bin. Solange kein usrmerge ausgeführt wurde, ist der Pfad im Cronjob dort oben also verkehrt.

[mat6937]

Ihr beiden dürftet auf dem richtigen Pfad sein. systemctl liegt in /bin, ...

... aber dann erst nach dem release-upgrade von Buster zu Bullseye? Denn der TE schreibt in seinem 1. Beitrag:

seit dem Update auf Debian 11 wird der cronjob ...

[MSfree]

systemctl liegt in /bin, nicht in /usr/bin.

Jessie:

Code: Alles auswählen

which systemctl
/bin/systemctl

Bullseye:

Code: Alles auswählen

which systemctl 
/usr/bin/systemctl
ls -li /bin/systemctl 
4195450 -rwxr-xr-x 1 root root 1058096 Jul 13 19:29 /bin/systemctl
ls -li /usr/bin/systemctl 
4195450 -rwxr-xr-x 1 root root 1058096 Jul 13 19:29 /usr/bin/systemctl

Unter Bullseye ist systemctl also "zweimal" vorhanden, einmal unter /usr/bin und einmal unter /bin. Physikalisch handelt es sich aber um eine Kopie, die nur als Hardlink in beide Verzeichnisse gelinkt ist, also auf die selbe Inode zeigen.

[TRex]

Funktioniert das denn ohne Session? Wenn ich zb mit su von root zu nem User wechsle und dessen user-services (systemd --user ...) managen möchte, klappte das früher mal nicht. Die richtige Terminologie fehlt mir hier, "Session" ist also nur unscharf zu betrachten. Ich halte das aber für die naheliegendere Ursache als Probleme mit dem Pfad.

[eikko]

Hallo,
erstmal Danke für alle die mitdenken!

Die Änderung auf "/bin/systemctl suspend >> /tmp/00log 2>&1" hat leider keine Änderung gebracht.

Das stand in den Log-Daten, falls das hilft:

07.09.21 23:55 CRON pam_unix(cron:session): session opened for user ich(uid=1000) by (uid=0)
07.09.21 23:55 CRON (ich) CMD (/bin/systemctl suspend >> /tmp/00log 2>&1)
07.09.21 23:55 CRON pam_unix(cron:session): session closed for user ich


Grüße eikko

[Draal]

Wie schon erwähnt, ohne Pfad funktioniert es, bei mir schon seit buster, über bullseye und auch in bookworm.

Code: Alles auswählen

# m h  dom mon dow   command
0 3 * * * systemctl restart systemd-timesyncd
5 3 * * * /sbin/hwclock -w

[MSfree]

Das stand in den Log-Daten, falls das hilft:

Code: Alles auswählen

07.09.21 23:55	CRON	pam_unix(cron:session): session opened for user ich(uid=1000) by (uid=0)

Daß du den Job unter deinem Benutzerkonto laufen läßt, hättest du auch von Anfang an sagen können

Für Dinge wie Suspend und Shutdown sind root-Rechte nötig. Wenn du Suspend als Benutzer von der Kommandozeile in der graphischen Umgebung startest, greifen die Regeln im Policy-Kit. Damit werden bestimmten Befehlen root-Rechte eingeräumt, auch wenn man selbst nicht root ist.

Unter cron wirkt das Policy-Kit nicht, daher wirst du schlicht keine Berechtigung haben, den Rechner zu suspendieren, wenn der cron-Job unter deinem Benutzerkonto läuft.

Hast du denn schonmal in die Datei /tmp/00log geschaut?

[eikko]

Ho MSfree,

ich hatte das schon mal als root laufen lassen, leider auch ohne Erfolg,
möglicherweise war da noch das "/usr/bin/systemctl" das Problem.

In /tmp/00log steht:

Failed to suspend system via logind: Interactive authentication required.
Failed to start suspend.target: Interactive authentication required.
See system logs and 'systemctl status suspend.target' for details.

Also vermutlich doch ein Rechteproblem!

Hat jemand nen Tip wie ich das elegant lösen könnte?

eikko

[JTH]

Also vermutlich doch ein Rechteproblem!

Ja, das ist genau das, was MSfree im vorigen Beitrag beschrieben hat.

Entweder du probierst es als systemweiter Cronjob.

Oder du könntest es über einen systemd-Timer lösen (ungetestet): Folgendes in /etc/systemd/system/suspend-at-midnight.timer:

Code: Alles auswählen

[Unit]
Description=Suspend at midnight

[Timer]
AccuracySec=1s
OnCalendar=23:55
Unit=suspend.target

[Install]
WantedBy=timers.target

Das Ganze einmal aktivieren:

Code: Alles auswählen

systemctl enable --now suspend-at-midnight.timer

[mat6937]

07.09.21 23:55 CRON pam_unix(cron:session): session opened for user ich(uid=1000) by (uid=0)

Hast das auf Buster (d. h. vor dem release-upgrade), aus der user-crontab funktioniert?

[eikko]

Hast das auf Buster (d. h. vor dem release-upgrade), aus der user-crontab funktioniert?

Ja, das lief jetzt jahrelang ohne Probleme,
erst seit dem Upgrade nicht mehr

Grüße eikko

[mat6937]

Ja, das lief jetzt jahrelang ohne Probleme,
erst seit dem Upgrade nicht mehr

Du hast in deinem 1. Beitrag auch geschrieben:

Wenn ich das per Hand starte funktioniert es problemlos.

Hast Du es "per Hand", als root oder als user gestartet, so dass es problemlos funktioniert hat?

[JTH]

Hast Du es "per Hand", als root oder als user gestartet, so dass es problemlos funktioniert hat?

Ob root oder normaler Benutzer ist dann normalerweise egal. (Inter-) aktiv von einem Benutzer ausgeführt (also im eigenen Terminal oder über die Wege des Desktops) darf einen Suspend auch ein normaler Benutzer auslösen. Das ist per PolicyKit so festgelegt (in /usr/share/polkit-1/actions/org.freedesktop.login1.policy im Abschnitt zu org.freedesktop.login1.suspend).

[mat6937]

Ob root oder normaler Benutzer ist dann normalerweise egal. (Inter-) aktiv von einem Benutzer ausgeführt (also im eigenen Terminal ...

"normalerweise", ... aber es gibt auch Ausnahmen. Hier z. B., nach einem release-upgrade sind root-Rechte erforderlich:

Code: Alles auswählen

:~$ shutdown -r now
shutdown: Administratorrechte (»root«-Rechte) benötigt

[JTH]

Code: Alles auswählen

:~$ shutdown -r now
shutdown: Administratorrechte (»root«-Rechte) benötigt

Zum Lernen und aus Interesse, wo die Meldung herkommt: Ist das denn ein System mit installiertem PolicyKit – und systemd? Bei letzterem hätte ich zumindest eine andere Rückmeldung erwartet.

[mat6937]

Zum Lernen und aus Interesse, wo die Meldung herkommt: Ist das denn ein System mit installiertem PolicyKit – und systemd?

PolicyKit ja und systemd nein. Es ist ein Beispiel und es taugt nicht zum lernen. Es geht mir nur um Informationen, die zur Verfügung gestellt werden sollten.

[eikko]

So, Rückmeldung!

Es läuft,
hab den Cronjob inzwischen als root und mit "/bin/systemctl" angelegt
und es wird jetz ausgeführt.

Vielen Dank an alle die mitgedacht haben!

Grüße eikko

[JTH]

PolicyKit ja und systemd nein. Es ist ein Beispiel und es taugt nicht zum lernen.

Warum nicht: Du hast mich daran erinnert, dass es ja weiterhin Systeme ohne systemd gibt und sich manches dort natürlich anders verhält. Man verliert ja bei manchen Antworten aus den Augen, dass es auch andere als "Standardsetups" gibt. (Auch wenns hier dem Titel nach explizit um eins mit systemd geht.)