comando no se ejecuta en cron (systemctl suspend)

12

Tengo este conjunto cronjob:

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

Y no está funcionando. Pero puedo ejecutarlo en un shell y funciona. No entiendo lo que podría no estar funcionando.

EDITAR error de redireccionamiento de salida para /tmp/errorda esto:

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

Mi pregunta es entonces: ¿Se ejecutan cronjobs como un usuario especial ( cronpor ejemplo), lo que explicaría que mi usuario puede ejecutar el comando, pero no él cronmismo?

Explicación adicional:

Este es un ejemplo mínimo para mostrar un problema que tengo en un script (eso tiene más sentido que el comando único proporcionado aquí)
systemctles parte de systemd. Creo que reiniciar, apagar, suspender funcionan con un usuario no root systemd. De todos modos, está funcionando en mi sistema.
Por último, yo uso Linux del arco y /bin, /usr/sbin, /sbinson todos los enlaces simbólicos a /usr/bin.

cron systemd suspend

— Degradado
fuente

1

¿Qué estás tratando de hacer exactamente aquí? ¿Qué hace el comando cuando lo ejecuta en el shell?

— terdon

Suspende mi computadora

— Gradient

¿Y quieres que eso suceda cada minuto? Tu systemctlestá dentro /usr/biny acepta suspendasí? ¿Qué * nix estás usando?

— terdon

1

No, es un ejemplo. En realidad, está en un script que se suspende cuando la batería tiene poca carga. Pero esta es la parte de mi script que no funciona. Traté de dar un ejemplo mínimo del problema (incluso si esto parece no tener sentido).

— Gradiente

2

OK, ya que esta pregunta está recolectando votos cerrados, edítela para agregar esta información adicional. Su distribución es importante ( systemctl suspendno funciona en las distribuciones de Debian o RedHat) y, por lo tanto, explica que en realidad no desea hacer lo que está mostrando :). Además, intente agregar 2> /tmp/erroro algo para capturar cualquier error que pueda estar recibiendo. Finalmente, díganos qué usuario está ejecutando este crontab.

— terdon

6

Realmente no puedo responder como tal, pero creo que puedo orientarte en la dirección correcta. Encontré esto en la página de Arch Wiki de systemd:

Polkit es necesario para la administración de energía. Si está en una sesión de usuario local systemd-logind y ninguna otra sesión está activa, los siguientes comandos funcionarán sin privilegios de root. Si no es así (por ejemplo, porque otro usuario ha iniciado sesión en un tty), systemd le pedirá automáticamente la contraseña de root.

[lista de varios comandos systemctl]

systemctl suspend

Esto me sugiere las siguientes posibilidades:

Tiene otro usuario conectado. ¿Quizás ha iniciado sesión a través de un tty?
cronejecuta sus comandos usando /bin/sh. Por defecto , en Arch esto es un enlace simbólico a /bin/bash. Esto significaría que cronestá iniciando un shell bash no interactivo que luego detecta que hay otra sesión de usuario ejecutándose (la suya), por lo que no tiene derecho a ejecutarse a systemctlpesar de ejecutarse como su usuario.

Entonces, si su problema se debe a cronque no está permitido ejecutarlo systemctlporque ya ha iniciado sesión, es posible que pueda solucionarlo jugando con polkit, pero no tengo experiencia allí, así que no puedo ayudarlo.

— terdon
fuente

¡Gracias! La primera opción se puede eliminar ya que puedo ejecutar el comando en un shell. Pero investigaré un poco más sobre la segunda opción.

— Gradiente

@Gradient, ¿descubriste cómo solucionar esto? Estoy luchando con el mismo problema.

— AkiRoss

¿Podría explicar la segunda posibilidad con más detalle? ¿Hay alguna manera de confirmar que este es realmente el problema? Ejecuté wy uptimedesde los scripts ejecutados por cron. Sus salidas indicaron que solo había un usuario. Entonces, ¿esto significa que hay algún otro problema?

— Anmol Singh Jaggi

3

Una solución fácil es usar el crontab de root en lugar del tuyo. Edítalo con:

$ sudo crontab -e

en lugar de:

$ crontab -e

— Frederik Baetens
fuente

Ejecuta los comandos como root en lugar de su usuario.

— Frederik Baetens

Esta no debería ser una práctica recomendada ... hacer que el comando funcione para el usuario.

— Plitter

1

Citando desde aquí :

¡La otra respuesta es genial! Pero requiere root cron.

Si desea hibernar desde un cron que no sea sudo, hay 2 opciones:

1. Usando polkit

Haga un archivo que contenga lo siguiente:
[Enable hibernate to be run via cron]
Identity=unix-user:*
Action=org.freedesktop.login1.hibernate;org.freedesktop.login1.hibernate-multiple-sessions
ResultAny=yes 
nombrado com.0.enable-hibernation-from-cron.pklaen el directorio /etc/polkit-1/localauthority/50-local.d/.

La explicación se da aquí .

2. Usando visudo

Citando desde aquí :
Si a los usuarios solo se les debe permitir usar los comandos de apagado, pero no tener otros privilegios de sudo, entonces, como root, agregue lo siguiente al final del /etc/sudoersuso del visudocomando.
user hostname =NOPASSWD: /usr/bin/systemctl poweroff,/usr/bin/systemctl halt,/usr/bin/systemctl reboot
Sustituya usersu nombre de usuario y hostnameel nombre de host de la máquina.
Ahora su usuario puede cerrar sudo systemctl poweroffy reiniciar con sudo systemctl reboot. Los usuarios que deseen apagar un sistema también pueden usarlo sudo systemctl halt.
Use la etiqueta NOPASSWD: solo si no desea que se le solicite su contraseña.
En mi caso, la línea exacta es:
anmol ALL=NOPASSWD: /bin/systemctl hibernate
(Tenga en cuenta que la ubicación de systemctlpodría ser diferente en su sistema).

Después de esto, puede escribir sudo systemctl hibernatefron cron para hibernar.

Nota: Modificar directamente /etc/sudoerses malo ; en su lugar, haga un archivo de sudoers personalizado /etc/sudoers.d/con el comando - sudo visudo -f /etc/sudoers.d/custom.

— Anmol Singh Jaggi
fuente

0

Si está utilizando el crontab del sistema, entonces olvida el campo de usuario. Tratar:

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

— Martin von Wittich
fuente

¿Estás seguro de que hay un campo de usuario? Nunca he visto un trabajo cron con él antes. De todos modos, el comando funciona cuando lo ejecuto como usuario en un shell.

— Gradiente

2

@Gradient, si está usando un campo de usuario /etc/crontab, ¿es este un crontab que creó cron -ecomo usuario normal?

— terdon

Es un crontab que creé con crontab -eun usuario normal.

— Gradiente

su cuenta de usuario normal probablemente no tenga permiso para ejecutarse systemctl suspendsin sudo.

— cas

0

Necesita usar el archivo de configuración systemd en /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
fuente