Tengo curiosidad por saber cuál es esta diferencia entre los programas que existen; comenzó con systemd cuando se habilitó a través de systemctl, frente a los que se iniciaron a /etc/rc.local
través de la CLI.
Por ejemplo, recientemente estaba usando shairport-sync para la frambuesa pi. Inicialmente, configuré shairport-sync para que se inicie mediante sudo systemctl shairport-sync habilitado.
Más adelante, utilicé una funcionalidad shairport-sync
para ejecutar scripts antes y publicar en dispositivos que se conectan.
Para mi sorpresa, los scripts cuando fueron ejecutados por shairport-sync
no lo hicieron kill
arecord
oaplay
Sin embargo, cuando ejecutaba el script a través del terminal, el script se ejecutaba y mataba arecord
y aplay
.
Para confundirme aún más, lo maté shairport-sync
y lo inicié a través de la terminal para ver la salida de lo que estaba sucediendo. Cuando lo hice, los scripts funcionaron como esperaba cuando el dispositivo se conectó y se apagó arecord
y aplay
. Por lo tanto, como una solución He desactivado shairport-sync
en sysmtectl
y configurarlo para que se ejecute en /etc/rc.local
como una solución rápida. Después de un reboot
funcionó como esperaba.
Esto me lleva a creer que hay alguna diferencia entre un programa que se ejecuta por separado systemd
y un programa que se ejecuta cuando se inicia a través de /etc/rc.local
la CLI.
¿Por qué pasó esto? ¿Esto se debe a los diferentes niveles de ejecución? ¿Un poco de magia oscura?
El script que se ejecuta cuando un dispositivo se conecta shairport-sync
es el siguiente:shairportstart.sh
#!/bin/sh
/usr/bin/sudo /bin/pkill arecord
if [ $(date +%H) -ge "18" -o $(date +%H) -le "7" ]; then
/usr/bin/amixer set Speaker 40%
else
/usr/bin/amixer set Speaker 100%
fi
/home/pi/shScripts/shairportfade.sh&
exit 0
Aquí está el script de desvanecimiento: shairportfade.sh
#!/bin/sh
/usr/bin/amixer set Speaker 30-
for (( i=0; i<30; i++))
do
/usr/bin/amixer set Speaker 1+
done
exit 0
El script que se ejecuta cuando un dispositivo se desconecta shairport-sync
es el siguiente:shairportend.sh
#!/bin/sh
/usr/bin/amixer set Speaker 70%
/usr/bin/arecord -D plughw:1 -f dat | /usr/bin/aplay -D plughw:1 -f dat&
exit 0
Encontré el siguiente error en el /var/log/syslog
único cuando shairport-sync se ejecutó inicialmente como parte de systemd
. Cuando shairport-sync
se ejecutó desde la CLI o /etc/rc.local
no hubo errores presentes.
Jan 24 00:38:45 raspberrypi shairport-sync[617]: sudo: no tty present and no askpass program specified
Tenga en cuenta que la única diferencia es cómo shairport-sync
se inicia inicialmente, cuando los dispositivos conectados o desconectados shairport-sync
continúan ejecutándose.
fuente
ps ... awk ... grep ...
material podría ser reemplazada por una simplepkill
/home/pi/shScripts/shairportfade.sh
?rc.local
Respuestas:
Variaciones de "¿Por qué las cosas se comportan de manera diferente bajo systemd?" son una pregunta frecuente
Cada vez que algo se ejecuta desde la CLI y no desde systemd, hay algunas categorías amplias de posibilidades para explicar las diferencias.
systemd
documenta las variables de entorno que pasaman systemd.exec
en la sección Variables de entorno en procesos generados . Si desea inspeccionar la diferencia usted mismo, puede usarlosystemd-run /path/to/binary
, ejecutará su aplicación en un ámbito transitorio, como lo haría un servicio systemd. Usted obtendrá una salida como:Running as unit: run-u160.service
. Luego puedejournalctl -u run-u160.service
revisar la salida. Modifique su aplicación para volcar las variables de entorno que recibe y compare la ejecución de CLI con la ejecución de systemd. Si la aplicación no se modifica convenientemente, puede usarlasystemd-run env
para ver las variables de entorno que se pasarían y revisar el registro de diario resultante. Si está intentando iniciar una aplicación X11 GUI, se debe establecer laDISPLAY
variable de entorno. En ese caso, considere usar la función de "inicio automático" de su entorno de escritorio en lugar desystemd
.man systemd.resource-control
los valores de configuración que podrían restringir el consumo de recursos. Utilícelosystemctl show your-unit-unit.service
para verificar los valores de configuración completos que afectan el servicio que intenta iniciar.bash
entorno CLI es un shell de inicio de sesión interactivo . Ha originado archivos como.bashrc
esesystemd
no. Además de establecer variables de entorno, estos scripts pueden hacer muchas otras cosas, como conectar un agente SSH para que las acciones SSH no requieran un inicio de sesión. Consulte también ¿ Diferencia entre Shell de inicio de sesión y Shell sin inicio de sesión?sudo
yssh
esperan al solicitar contraseñas. Ver también sudo: no hay tty presente y no se especificó el programa askpassman systemd.service
, el primer argumentoExecStart=
debe ser una ruta absoluta a un binario.systemd
tienen una sintaxis de línea de comandos muy restringida . Dependiendo de sus necesidades, puede replicar la sintaxis de Shellsystemd
ejecutando explícitamente su comando a través de un shell:ExecStart=/bin/bash -c '/my/bash $(syntax) >/goes-here.txt'
Es una característica que el sistema ejecuta su código en un entorno consistente con controles de recursos. Esto ayuda con resultados reproducibles y estables a largo plazo sin abrumar al hardware.
fuente
sudo
un script de shell que se ejecute mejorsudo shairportstart.sh
desde la terminal, ya que systemd ejecuta el script como root, no es necesario sudo como root./usr/bin/echo "mypassword" | /usr/bin/sudo /bin/pkill arecord
. Más tarde hoy, intentaré eliminar los comandossudo
yecho
de mi comando kill y ver si eso arroja los mismos resultados. Supongo que funcionará, ya que parece que el error fue causado por el envío de una contraseña con elsudo
comando. Gracias por la ayuda para comprender por qué hay una diferencia entresystemd
y la CLI