comando non in esecuzione in cron (systemctl suspend)

12

Ho questo set cronjob:

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

E non funziona. Ma posso eseguirlo in una shell e funziona. Non capisco cosa potrebbe non funzionare.

EDIT Reindirizzare l'output dell'errore per /tmp/errordare questo:

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

La mia domanda è quindi: cronjobs viene eseguito come utente speciale ( cronad esempio), il che spiegherebbe che il mio utente può eseguire il comando, ma non cronse stesso?

Spiegazione aggiuntiva:

Questo è un esempio minimo per mostrare un problema che ho in uno script (ha più senso del singolo comando fornito qui)
systemctlfa parte di systemd. Penso che il riavvio, l'arresto, la sospensione stiano funzionando con un utente non root con systemd. Ad ogni modo, sta funzionando sul mio sistema.
Infine, io uso Arch Linux e /bin, /usr/sbin, /sbinsono tutti i collegamenti simbolici a /usr/bin.

cron systemd suspend

— Pendenza
fonte

1

Cosa stai esattamente cercando di fare qui? Cosa fa il comando quando lo si esegue nella shell?

— Terdon

Sospende il mio computer

— Gradiente

E vuoi che ciò accada ogni minuto? Il tuo systemctlè dentro /usr/bine accetta suspendcosì? Che * nix stai usando?

— Terdon

1

No, è un esempio. In realtà è in uno script che si sospende quando la batteria è scarica. Ma questa è la parte della mia sceneggiatura che non funziona. Ho provato a dare un esempio minimo del problema (anche se questo sembra non avere senso).

— Gradiente

2

OK, poiché questa domanda sta raccogliendo voti stretti, si prega di modificarlo per aggiungere queste informazioni extra. La tua distribuzione è importante ( systemctl suspendnon funziona su distribuzioni Debian o RedHat) e quindi spiega che non vuoi davvero fare quello che stai mostrando :). Inoltre, prova ad aggiungere 2> /tmp/erroro qualcosa per catturare eventuali errori che potresti riscontrare. Infine, dicci quale utente sta eseguendo questo crontab.

— Terdon

6

Non posso davvero rispondere come tale, ma penso di poterti indirizzare nella giusta direzione. L'ho trovato nella pagina Arch Wiki di systemd:

polkit è necessario per la gestione dell'alimentazione. Se ci si trova in una sessione utente locale di systemd-logind e nessuna altra sessione è attiva, i seguenti comandi funzioneranno senza i privilegi di root. In caso contrario (ad esempio perché un altro utente ha effettuato l'accesso a tty), systemd ti chiederà automaticamente la password di root.

[elenco di vari comandi systemctl]

systemctl suspend

Questo mi suggerisce le seguenti possibilità:

Hai un altro utente connesso. Forse hai effettuato l'accesso tramite un tty?
cronesegue i suoi comandi utilizzando /bin/sh. Per impostazione predefinita , su Arch questo è un link simbolico a /bin/bash. Ciò significherebbe che cronsta avviando una shell bash non interattiva che rileva quindi che è in esecuzione un'altra sessione utente (la tua), quindi non ha il diritto di eseguire systemctlnonostante sia in esecuzione come utente.

Quindi, se il tuo problema è perché cronnon è possibile eseguire systemctlperché sei già connesso, potresti essere in grado di aggirare questo giocando con polkit ma non ho esperienza lì, quindi non posso aiutare.

— terdon
fonte

Grazie! La prima opzione può essere eliminata poiché sono in grado di eseguire il comando in una shell. Ma farò qualche ricerca in più sulla seconda opzione.

— Pendenza

@Gradient hai scoperto come risolvere questo problema? Sto lottando con lo stesso problema.

— AkiRoss,

Potresti spiegare la seconda possibilità in modo più dettagliato? C'è un modo per confermare che questo è davvero il problema? Ho eseguito we uptimedagli script eseguiti da cron. Le loro uscite indicavano che c'era solo l'utente. Quindi, questo significa che c'è qualche altro problema?

— Anmol Singh Jaggi,

3

Una soluzione semplice è usare il crontab di root invece del tuo. Modificalo con:

$ sudo crontab -e

invece di:

$ crontab -e

— Frederik Baetens
fonte

Esegue i comandi come root anziché come utente.

— Frederik Baetens l'

Questa non dovrebbe essere una pratica consigliata ... far funzionare il comando per l'utente.

— Plitter

1

Citando da qui :

L'altra risposta è fantastica! Ma richiede il cron root.

Se vuoi ibernare da cron non sudo, ci sono 2 opzioni:

1. Utilizzo di polkit

Crea un file contenente quanto segue:
[Enable hibernate to be run via cron]
Identity=unix-user:*
Action=org.freedesktop.login1.hibernate;org.freedesktop.login1.hibernate-multiple-sessions
ResultAny=yes 
nominato com.0.enable-hibernation-from-cron.pklanella directory /etc/polkit-1/localauthority/50-local.d/.

La spiegazione è fornita qui .

2. Utilizzo di visudo

Citando da qui :
Se agli utenti deve essere consentito solo l'uso dei comandi di arresto, ma non avere altri privilegi di sudo, quindi, come root, aggiungere quanto segue alla fine /etc/sudoersdell'uso del visudocomando.
user hostname =NOPASSWD: /usr/bin/systemctl poweroff,/usr/bin/systemctl halt,/usr/bin/systemctl reboot
Sostituisci il usertuo nome utente e hostnameil nome host della macchina.
Ora l'utente può arrestare con sudo systemctl poweroffe riavviare con sudo systemctl reboot. Gli utenti che desiderano spegnere un sistema possono anche utilizzare sudo systemctl halt.
Utilizzare il tag NOPASSWD: solo se non si desidera che venga richiesta la password.
Nel mio caso, la riga esatta è:
anmol ALL=NOPASSWD: /bin/systemctl hibernate
(Nota che la posizione di systemctlpotrebbe essere diversa sul tuo sistema.)

Dopodiché, puoi scrivere da sudo systemctl hibernatecron a ibernazione.

Nota: la modifica diretta /etc/sudoersè errata ; invece crea un file sudoers personalizzato sotto /etc/sudoers.d/usando il comando - sudo visudo -f /etc/sudoers.d/custom.

— Anmol Singh Jaggi
fonte

0

Se stai usando il crontab di sistema, allora dimentichi il campo utente. Provare:

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

— Martin von Wittich
fonte

Sei sicuro che ci sia un campo utente? Non ho mai visto un cronjob con esso prima. Ad ogni modo, il comando funziona quando lo eseguo come utente in una shell.

— Gradiente

2

@Gradient c'è un campo utente se stai usando /etc/crontab, è questo un crontab che hai creato cron -ecome tuo normale utente?

— Terdon

È un crontab che ho creato crontab -ecome utente normale.

— Gradiente

il tuo normale account utente probabilmente non ha i permessi per funzionare systemctl suspendsenza sudo.

— Cas

0

È necessario utilizzare il file di configurazione di systemd in /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
fonte