¿Por qué systemd notifica fallas en mi servicio si ejecuto un script con sudo?
Estoy creando un servicio systemd que necesita ejecutar un script bash con sudo privs. Me di cuenta de que cuando lo ejecuto, se cuelga para siempre en "status = Activating".
Para intentar replicarlo, configuro un ejemplo de juguete. Tengo una unidad systemd que ejecutará un script bash de larga duración muy simple que hace un systemd_notify de inmediato y luego se repite para siempre. Ejecuto el script con sudo. Sin embargo, el servicio no se inicia y aparece este error:
Aug 20 14:21:48 ip-10-110-103-202 systemd[1]: Starting "Testing"...
Aug 20 14:21:49 ip-10-110-103-202 sudo[24772]: No status data could be sent: $NOTIFY_SOCKET was not set
Aug 20 14:21:49 ip-10-110-103-202 systemd[1]: test.service: Main process exited, code=exited, status=1/FAILURE
test.service:
[Unit]
Description="Testing"
Requires=network-online.target
After=network-online.target
[Service]
Type=notify
User=consul
Group=consul
ExecStart=/usr/bin/sudo /home/psengupta/long_test.sh
[Install]
WantedBy=multi-user.target
long_test.sh:
!/usr/bin/env bash
set -euo pipefail
systemd-notify --ready --status="Started"
while true
do
echo "Press CTRL+C to stop the script execution"
# Enter your desired command in this block.
done
Cuando elimino el sudo delante del comando, ¡funciona bien! por ejemplo, ExecStart = / home / psengupta / long_test.sh
¿Por qué el uso de sudo antes de ejecutar el script long_test.sh falla realmente en mi servicio? No estoy muy familiarizado con estas cosas y no estoy seguro de por qué $ NOTIFY_SOCKET no está configurado con el uso del comando sudo. Idealmente, me gustaría configurarlo y ejecutar el script con sudo y notificar cuando se inicia.
Respuestas
Lea man sudo sudoers
y use sudo -E
para transmitir todo su conjunto de variables de entorno.