¿El sustituto correcto para Rc.local en Systemd en lugar de volver a crear Rc.local?

No puedo encontrar la forma correcta de ejecutar algunos local scripts (o comandos muy locales) en systemd, ya sé que no debo crear un servicio (en systemd una unidad) para este tipo de scripts (¿o debo hacerlo?)….

La solución que encontré es crear rc.local y otorgarle permisos de ejecución.

printf '#!/bin/bash nnexit 0' >/etc/rc.local 
chmod +x /etc/rc.local

Por ejemplo, si obtengo un servidor heredado con un rc.local simple configurado por usted, sabré qué hizo y cuánto me va a doler actualizar o instalar algo nuevo en la distribución, ya que rc.local fue respetado por externos. paquetes, pero por otro lado si instalo un servidor y creo una unidad systemd o dos o tres (o incluso servicios sysvinit), solo por hacer una tarea simple, esto a veces puede hacer su vida más difícil, y mucho más que esto mis unidades Algún día, los nombres pueden entrar en conflicto con los nombres de los nuevos servicios creados por el desarrollo de la distribución, y tal vez instalados en una actualización, ¡causando problemas para mis scripts!

Veo otra pregunta preguntando sobre dónde está rc.local y la respuesta fue crearlo y darle permisos de ejecución, creo que mi pregunta es realmente no un duplicado , porque no quiero saber dónde está, créeme, solo quiero aceptar que está en desuso , pero no puedo encontrar la forma correcta de hacer este tipo de cosas, ¿realmente debería crear una unidad solo para algo así?

Respuesta aceptada:

Como se señaló en otra parte, se vuelve moderadamente impuro usar rc-local.service en systemd .

1. En teoría, es posible que su distribución no lo habilite. (Creo que esto no es común, por ejemplo, porque deshabilitar la misma opción de compilación también elimina poweroff / reboot comandos que usa mucha gente).
2. La semántica no está del todo clara. Systemd define rc-local.service de una manera, pero Debian proporciona un archivo desplegable que modifica al menos una configuración importante.

rc-local.service a menudo puede funcionar bien. Si le preocupa lo anterior, ¡todo lo que necesita hacer es hacer su propia copia! Aquí está la magia:

# /etc/systemd/system/my-startup.service
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/local/libexec/my-startup-script

[Install]
WantedBy=multi-user.target

No creo que debas entender cada detalle[*], pero hay dos cosas que debes saber aquí.

1. Debe habilitar esto con systemctl enable my-startup.service .

2. Si su secuencia de comandos depende de cualquier otro servicio, incluido network-online.target , debes declararlo. P.ej. agregar un [Unit] sección, con las líneas Wants=network-online.target y After=network-online.target .

   No necesita preocuparse por las dependencias de los servicios de "arranque temprano", específicamente, los servicios que ya se ordenaron antes de basic.target . Servicios como my-startup.service se ordenan automáticamente después de basic.target , a menos que establezcan DefaultDependencies=no .

   Si no está seguro de si una de sus dependencias es un servicio de "arranque temprano", un enfoque es enumerar los servicios que se solicitan antes de basic.target , ejecutando systemctl list-dependencies --after basic.target . (Tenga en cuenta que es --after , no --before ).

Relacionado:¿Obtener el script para que se ejecute de nuevo si la entrada es sí?

Hay algunas consideraciones que creo que también se aplicaron a pre-systemd rc.local :

1. Debe asegurarse de que sus comandos no entren en conflicto con otro programa que intente controlar lo mismo.
2. Es mejor no iniciar programas de ejecución prolongada, también conocidos como demonios, desde rc.local .

[*] Usé Type=oneshot + RemainAfterExit=yes porque tiene más sentido para la mayoría de los guiones one-shot. Formaliza que ejecutará una serie de comandos, que my-startup se mostrarán como "activos" una vez que se hayan completado, y que no iniciará un demonio.