¿Diferencia entre Systemd y el programa de inicio de terminal?

Tengo curiosidad por saber cuál es esta diferencia entre los programas que son; comenzó con systemd cuando se habilitó a través de systemctl, frente a los iniciados mediante /etc/rc.local o a través de la CLI.

Por ejemplo, recientemente estuve usando shairport-sync para la raspberry pi. Inicialmente, configuré shairport-sync para que se iniciara mediante sudo systemctl habilitado shairport-sync.

Más adelante utilicé una funcionalidad dentro de shairport-sync para ejecutar scripts antes y publicarlos en los dispositivos que se conectan.

Para mi sorpresa, los scripts cuando son ejecutados por shairport-sync no kill arecord o aplay

Sin embargo, cuando ejecutaba el script a través de la terminal, el script se ejecutaba y eliminaba arecord y aplay .

Para confundirme aún más, eliminé shairport-sync y lo inicié a través de la terminal para ver el resultado de lo que estaba sucediendo. Cuando lo hice, los scripts funcionaron como esperaba cuando el dispositivo se conectó y eliminó arecord y aplay . Entonces, como solución, deshabilité 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 aparte de systemd y un programa que se ejecuta cuando se inicia a través de /etc/rc.local o la CLI.

¿Por qué pasó esto? ¿Es esto debido a los diferentes niveles de ejecución? ¿Algo de magia oscura?

El script que se ejecuta cuando un dispositivo se conecta a 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 fundido: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 de 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 /var/log/syslog solo 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 se conectan o desconectan shairport-sync sigue funcionando.

Respuesta aceptada:

Variaciones de “¿Por qué las cosas se comportan de manera diferente en systemd?” son una pregunta frecuente.

Cada vez que algo se ejecuta desde la CLI y no desde systemd, existen algunas categorías amplias de posibilidades para tener en cuenta las diferencias.

1. Diferentes variables de entorno . systemd documenta las variables de entorno que pasa en man systemd.exec en la sección Variables de entorno en procesos generados. Si desea inspeccionar la diferencia usted mismo, puede usar systemd-run /path/to/binary , ejecutará su aplicación en un ámbito transitorio, como lo haría un servicio systemd. Obtendrá resultados como:Running as unit: run-u160.service . A continuación, puede journalctl -u run-u160.service para 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 usar systemd-run env para ver las variables de entorno que se pasarían y revisar el registro diario resultante. Si está intentando iniciar una aplicación GUI X11, el DISPLAY la variable de entorno debe establecerse. En ese caso, considere usar la función de "inicio automático" de su entorno de escritorio en lugar de systemd .
2. Restricciones de recursos . Ver man systemd.resource-control para valores de configuración que podrían restringir el consumo de recursos. Use systemctl show your-unit-unit.service para comprobar los valores de configuración completos que afectan al servicio que intenta iniciar.
3. Shell no interactivo . Tu bash El entorno CLI es un shell de inicio de sesión interactivo . Tiene archivos de origen como .bashrc que systemd no tiene 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?
4. Sin TTY . Su sesión interactiva está conectada a un TTY que algunos programas como sudo y ssh esperar cuando se le soliciten contraseñas. Ver también sudo:no hay tty presente y no se especificó ningún programa askpass
5. Rutas relativas y absolutas . Trabajo binario relativo en el shell, pero como se documenta en man systemd.service , el primer argumento de ExecStart= debe ser una ruta absoluta a un binario.
6. Sintaxis de línea de comando restringida . Shell CLI admite muchos metacaracteres, mientras que systemd tiene una sintaxis de línea de comando muy restringida. Según sus necesidades, es posible que pueda replicar la sintaxis de Shell con systemd 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 a obtener resultados estables y reproducibles a largo plazo sin sobrecargar el hardware.

Relacionado:¿Qué indica este proceso STAT?