Befehl läuft nicht in cron (systemctl suspend)

12

Ich habe diesen Cronjob eingestellt:

* * * * * /usr/bin/systemctl suspend

Und es funktioniert nicht. Aber ich kann es in einer Shell ausführen und es funktioniert. Ich verstehe nicht, was nicht funktionieren könnte.

EDIT Umleitung der Fehlerausgabe zu /tmp/error:

Failed to issue method call: Access denied
Failed to issue method call: Access denied

Meine Frage lautet dann: Werden Cronjobs beispielsweise als Spezialbenutzer ausgeführt cron, was erklären würde, dass mein Benutzer den Befehl ausführen kann, aber nicht cronselbst?

Zusätzliche Erklärung:

Dies ist ein minimales Beispiel für ein Problem in einem Skript (das sinnvoller ist als der hier angegebene einzelne Befehl).
systemctlist ein Teil von systemd. Ich denke Neustart, Herunterfahren, Suspendieren arbeiten mit einem Nicht-Root-Benutzer mit systemd. Wie auch immer, es funktioniert auf meinem System.
Schließlich verwende ich Arch Linux und /bin, /usr/sbin, /sbinsind alle Symlinks /usr/bin.

cron systemd suspend

— Gradient
quelle

1

Was genau versuchst du hier zu tun? Was macht der Befehl, wenn Sie ihn in der Shell ausführen?

— Terdon

Mein Computer wird angehalten

— Gradient

Und willst du, dass das jede Minute passiert? Sie systemctlist in /usr/binund akzeptiert suspendwie das? Was * nix benutzt du?

— Terdon

1

Nein, es ist ein Beispiel. Es ist eigentlich in einem Skript, das angehalten wird, wenn die Batterie schwach ist. Aber das ist der Teil in meinem Skript, der nicht funktioniert. Ich habe versucht, ein minimales Beispiel für das Problem zu geben (auch wenn dies keinen Sinn zu ergeben scheint).

— Gradient

2

OK, da diese Frage enge Abstimmungen sammelt, bearbeiten Sie sie bitte , um diese zusätzlichen Informationen hinzuzufügen. Ihre Distribution ist wichtig ( systemctl suspendfunktioniert nicht in Debian- oder RedHat-Distributionen) und erklärt auch, dass Sie nicht wirklich das tun möchten, was Sie anzeigen :). Versuchen 2> /tmp/errorSie auch, Fehler hinzuzufügen oder zu erfassen, die möglicherweise auftreten. Sagen Sie uns abschließend, welcher Benutzer diese crontab ausführt.

— Terdon

6

Ich kann als solche nicht wirklich antworten, aber ich denke, ich kann Sie in die richtige Richtung weisen. Ich fand dies in der Arch Wiki- Seite von systemd:

Für die Energieverwaltung ist ein Polkit erforderlich. Wenn Sie sich in einer lokalen Benutzersitzung systemd-logind befinden und keine andere Sitzung aktiv ist, funktionieren die folgenden Befehle ohne Root-Berechtigungen. Wenn dies nicht der Fall ist (z. B. weil ein anderer Benutzer bei tty angemeldet ist), werden Sie von systemd automatisch nach dem root-Passwort gefragt.

[Liste verschiedener systemctl-Befehle]

systemctl suspend

Dies schlägt mir folgende Möglichkeiten vor:

Sie haben einen anderen Benutzer angemeldet. Vielleicht haben Sie sich über ein tty angemeldet?
cronführt seine Befehle mit /bin/sh. In Arch ist dies standardmäßig ein Symlink zu /bin/bash. Dies würde bedeuten, dass croneine nicht interaktive Bash-Shell gestartet wird, die dann erkennt, dass eine andere Benutzersitzung ausgeführt wird (Ihre), sodass sie systemctltrotz Ausführung als Benutzer nicht zur Ausführung berechtigt ist .

Wenn Ihr Problem also darin besteht, dass crones nicht ausgeführt werden darf, systemctlweil Sie bereits angemeldet sind, können Sie das möglicherweise umgehen , indem Sie mit Polkit spielen, aber ich habe dort keine Erfahrung, sodass ich nicht helfen kann.

— terdon
quelle

Vielen Dank! Die erste Option kann weggelassen werden, da ich den Befehl in einer Shell ausführen kann. Aber ich werde die zweite Option etwas genauer untersuchen.

— Gradient

@Gradient hast du entdeckt, wie man das behebt? Ich habe mit dem gleichen Problem zu kämpfen.

— AkiRoss

Könnten Sie bitte die zweite Möglichkeit näher erläutern? Gibt es eine Möglichkeit zu bestätigen, dass dies tatsächlich das Problem ist? Ich habe ausgeführt wund uptimeaus den Skripten von Cron ausgeführt. Ihre Ausgaben zeigten an, dass es nur Benutzer gab. Bedeutet dies, dass es ein anderes Problem gibt?

— Anmol Singh Jaggi

3

Eine einfache Problemumgehung besteht darin, die crontab von root anstelle Ihrer eigenen zu verwenden. Bearbeiten Sie es mit:

$ sudo crontab -e

Anstatt von:

$ crontab -e

— Frederik Baetens
quelle

Es führt die Befehle als root und nicht als Benutzer aus.

— Frederik Baetens

Dies sollte keine empfohlene Vorgehensweise sein. Stellen Sie sicher, dass der Befehl für den Benutzer funktioniert.

— Plitter

1

Zitat von hier :

Die andere Antwort ist großartig! Dafür ist jedoch Rootcron erforderlich.

Wenn Sie von einem Nicht-Sudo-Cron aus in den Ruhezustand wechseln möchten, gibt es zwei Möglichkeiten:

1. Polkit verwenden

Erstellen Sie eine Datei, die Folgendes enthält:
[Enable hibernate to be run via cron]
Identity=unix-user:*
Action=org.freedesktop.login1.hibernate;org.freedesktop.login1.hibernate-multiple-sessions
ResultAny=yes 
Namen com.0.enable-hibernation-from-cron.pklaim Verzeichnis /etc/polkit-1/localauthority/50-local.d/.

Erklärung wird hier gegeben .

2. Mit visudo

Zitat von hier :
Wenn Benutzer nur Shutdown-Befehle verwenden dürfen, aber keine anderen Sudo-Berechtigungen haben sollen, fügen Sie als Root-Benutzer am Ende der /etc/sudoersVerwendung des visudoBefehls Folgendes hinzu .
user hostname =NOPASSWD: /usr/bin/systemctl poweroff,/usr/bin/systemctl halt,/usr/bin/systemctl reboot
Ersetzen Sie userIhren Benutzernamen und hostnameden Hostnamen des Computers.
Jetzt kann Ihr Benutzer mit herunterfahren sudo systemctl poweroffund mit neu starten sudo systemctl reboot. Benutzer, die ein System ausschalten möchten, können ebenfalls verwenden sudo systemctl halt.
Verwenden Sie das Tag NOPASSWD: nur, wenn Sie nicht zur Eingabe Ihres Kennworts aufgefordert werden möchten.
In meinem Fall ist die genaue Zeile:
anmol ALL=NOPASSWD: /bin/systemctl hibernate
(Beachten Sie, dass sich der Speicherort von systemctlauf Ihrem System möglicherweise unterscheidet.)

Danach können sudo systemctl hibernateSie von cron in den Ruhezustand schreiben .

Hinweis: Das direkte Ändern /etc/sudoersist schlecht . Erstellen Sie stattdessen eine benutzerdefinierte sudoers-Datei /etc/sudoers.d/mit dem Befehl - sudo visudo -f /etc/sudoers.d/custom.

— Anmol Singh Jaggi
quelle

0

Wenn Sie die System-Crontab verwenden, vergessen Sie das Benutzerfeld. Versuchen:

* * * * * root /usr/bin/systemctl suspend

— Martin von Wittich
quelle

Sind Sie sicher, dass es ein Benutzerfeld gibt? Ich habe noch nie einen Cronjob damit gesehen. Auf jeden Fall funktioniert der Befehl, wenn ich ihn als Benutzer in einer Shell ausführe.

— Gradient

2

@Gradient Wenn Sie ein Benutzerfeld verwenden /etc/crontab, ist dies eine Crontab, mit der Sie cron -eals normaler Benutzer erstellt haben?

— Terdon

Es ist eine Crontab, mit der ich crontab -eals normaler Benutzer erstellt habe.

— Gradient

Ihr normales Benutzerkonto hat wahrscheinlich keine Berechtigung, systemctl suspendohne sudo zu laufen .

— cas

0

Sie müssen die Konfigurationsdatei systemd in verwenden /etc/systemd/system

[Unit]
Description=Pimcore Events Processor

[Service]
WorkingDirectory=/var/www/html
ExecStart=/usr/bin/php run something
Restart=always
WatchdogSec=300 #in seconds
User=www-data
Group=www-data

[Install]
WantedBy=multi-user.target

— James M
quelle