No puedo encontrar la forma correcta de ejecutar algunos scripts locales (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 darle permisos de ejecución.

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

Por ejemplo, si obtengo un servidor heredado con un simple rc.local 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 a mis scripts.

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

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

1. Es teóricamente 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/ rebootcomandos que mucha gente usa).
2. La semántica no está del todo clara. Systemd define rc-local.serviceuna forma, pero Debian proporciona un archivo desplegable que modifica al menos una configuración importante.

rc-local.serviceA 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 necesite comprender cada detalle [*], pero hay dos cosas que debe saber aquí.

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

2. Si su script tiene una dependencia de cualquier otro servicio, incluido network-online.target, debe declararlo. Por ejemplo, agregue una [Unit]sección, con las líneas Wants=network-online.targety After=network-online.target.

   No necesita preocuparse por las dependencias de los servicios de "arranque temprano", específicamente, los servicios que ya se ordenaron anteriormente basic.target. Los servicios como my-startup.servicese ordenan automáticamente después basic.target, a menos que se 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 ordenaron antes basic.target, ejecutándose systemctl list-dependencies --after basic.target. (Tenga en cuenta que --afterno --before).

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 larga duración, también conocidos como daemons rc.local.

[*] Utilicé Type=oneshot+ RemainAfterExit=yesporque tiene más sentido para la mayoría de los scripts de una sola vez. Se formaliza que ejecutará una serie de comandos, que my-startupse mostrarán como "activos" una vez que se hayan completado, y que no iniciará un demonio.

Olvidarse de rc.local.

Como dije sobre CentOS 7 y sobre Debian 8 y sobre Ubuntu 15 :

Estás utilizando un sistema operativo systemd + Linux. /etc/rc.locales un doble mecanismo de compatibilidad con versiones anteriores en systemd, porque es un mecanismo de compatibilidad con versiones anteriores para un mecanismo que era en sí mismo un mecanismo de compatibilidad en el clon del Sistema 5 de Van Smoorenburg rc.

Usar /etc/rc.localpuede salir terriblemente mal. La gente se ha sorprendido por el hecho de que systemd no se ejecuta rc.localde la misma manera, en el mismo lugar en el arranque, como solía hacerlo. (O erróneamente espere: de hecho, no se ejecutó por última vez en el sistema anterior, como todavía señala el manual de OpenBSD). Otros se han sorprendido por el hecho de que lo que establecieron al rc.localesperar las viejas formas de hacer las cosas, es entonces completamente deshecho por los gustos de las nuevas udevnormas, NetworkManager, systemd-logind, systemd-resolved, o varios "kit" s.

Como se ejemplifica en " ¿Por qué` init 0` resulta en "Argumentos excesivos" en la instalación de Arch? ", Algunos sistemas operativos ya proporcionan systemd sin las características de compatibilidad con versiones anteriores , como el systemd-rc-local-generatorgenerador . Mientras Debian aún conserva las características de compatibilidad con versiones anteriores , Arch Linux construye systemd con ellas desactivadas . Entonces, en Arch y sistemas operativos como este, se espera /etc/rc.local que se ignore por completo .

Olvidarse de rc.local. No es el camino a seguir. Tiene un sistema operativo systemd + Linux. Por lo tanto, cree una unidad de servicio systemd adecuada y no comience desde un punto que esté a dos niveles de compatibilidad con versiones anteriores. (En Ubuntu y Fedora, se eliminó tres veces, el clon de Van Smoorenburg System 5 rcque siguió rc.localluego fue reemplazado dos veces , hace más de una década, primero por advenedizo y luego por systemd).

Recuerde también la primera regla para migrar a systemd .

Esto ni siquiera es una idea nueva que sea específica de systemd. En los sistemas van Smoorenburg rcy Upstart, lo que había que hacer era crear un rcscript de van Smoorenburg o un archivo de trabajo Upstart adecuado en lugar de usarlos rc.local. Incluso el manual de FreeBSD señala que hoy en día uno crea un rcscript Mewburn adecuado en lugar de usarlo /etc/rc.local. Mewburn rcfue presentado por NetBSD 1.5 en 2000.

/etc/rc.localdata de la época de la Séptima Edición Unix y anteriores. Fue reemplazado /etc/inittaby basado rcen un nivel de ejecución en AT&T Unix System 3 (con un poco diferente /etc/inittaben AT&T Unix System 5) en 1983 . Incluso eso es ahora historia.

Cree definiciones de servicio nativas adecuadas para su sistema de gestión de servicios, ya sea un paquete de servicios para el conjunto de herramientas nosh service-managery system-control, un /etc/rc.d/script para Mewburn rc, un archivo de unidad de servicio para systemd, un archivo de trabajo para Upstart, un directorio de servicio para runit / s6 / daemontools -encore, o incluso un /etc/init.d/guión para van Smoorenburg rc.

En systemd, estos archivos de unidad de servicio agregados por el administrador entran /etc/systemd/system/generalmente (o /usr/local/lib/systemd/system/raramente). Con el administrador de servicios nosh, /var/local/sv/es un lugar convencional para paquetes de servicios locales. Mewburn rcen los usos de FreeBSD /usr/local/etc/rc.d/. Sin embargo, los archivos de la unidad de servicio empaquetada y los paquetes de servicio, si los está haciendo, van a diferentes lugares.

Otras lecturas

• Lennart Poettering y col. (2014) systemd-rc-local-generator . páginas de manual de systemd. Freedesktop.org.
• rc.local. Manual del administrador del sistema FreeBSD . 2016-04-23.
• /unix//a/233581/5132
• Lennart Poettering (2011-08-29). Plese retire /etc/rc.localo chmod -xse . Error de Redhat # 734268.
• /unix//a/211927/5132
• Dirk Schmitt (19-12-2017). rc.localEstá empezando a temprano . error systemd # 7703
• https://wiki.archlinux.org/index.php?title=Systemd&diff=378926&oldid=378924
• Benjamin Cane (30/12/2011). Cuando está bien y no está bien usarrc.local . bencane.com.
• /unix//a/49636/5132
• Lennart Poettering (2010-10-01). ¿Cómo convierto un script de inicio SysV en un archivo de servicio systemd? . 0pointer.de.
• /ubuntu/523369/
• Jonathan de Boyne Pollard (2015). /etc/inittabEs cosa del pasado. . Respuestas frecuentes.
• Jonathan de Boyne Pollard (2014). Una mirada en paralelo a los scripts de ejecución y las unidades de servicio. . Respuestas frecuentes.
• Jonathan de Boyne Pollard (2014). Un ejemplo del mundo real de cómo configurar y ejecutar un servicio con nosh . Softwares
• Jonathan de Boyne Pollard (2016). " Faltan rutas de búsqueda del sistema en la systemd.unitpágina del manual ". Erratas para systemd doco . Respuestas frecuentes.

Resumen de https://www.linuxbabe.com/linux-server/how-to-enable-etcrc-local-with-systemd

Cree /etc/systemd/system/rc-local.service:

# /etc/systemd/system/rc-local.service
[Unit]
 Description=/etc/rc.local Compatibility
 ConditionPathExists=/etc/rc.local

[Service]
 Type=forking
 ExecStart=/etc/rc.local start
 TimeoutSec=0
 StandardOutput=tty
 RemainAfterExit=yes
 SysVStartPriority=99

[Install]
 WantedBy=multi-user.target

Luego:

sudo touch /etc/rc.local
sudo chmod +x /etc/rc.local
sudo systemctl enable rc-local

Verifícalo con:

sudo systemctl start rc-local.service
sudo systemctl status rc-local.service