Esta noticia ha sido analizado por expertos así garantizamos la veracidad de este escrito.
Solución:
La respuesta del caos es lo que dice alguna documentación. Pero no es lo que realmente hace systemd. (No es lo que van Smoorenburg rc tampoco lo hizo. El van Smoorenburg rc definitivamente No ignorar los encabezados LSB, que insserv usado para calcular static pedidos, para empezar.) La documentación de Freedesktop, como la página “Incompatibilidades”, es de hecho incorrecta, en estos y otros puntos. (Los HOME variable de entorno de hecho es a menudo, por ejemplo. Esto estuvo completamente indocumentado en cualquier lugar durante mucho tiempo. Ahora está documentado en el manual, al menos, pero esa página de Freedesktop WWW aún no se ha corregido).
El formato de servicio nativo para systemd es el unidad de servicio. La gestión de servicios de systemd funciona correctamente. solamente en términos de aquellos, que lee de uno de los nueve directorios donde (en todo el sistema) .service los archivos pueden vivir. /etc/systemd/system, /run/systemd/system, /usr/local/lib/systemd/system, y /usr/lib/systemd/system son cuatro de esos directorios.
La compatibilidad con van Smoorenburg rc scripts se logra con un programa de conversión, llamado systemd-sysv-generator. Este programa está listado en el /usr/lib/systemd/system-generators/ directorio y, por lo tanto, systemd lo ejecuta automáticamente al principio del proceso de arranque en cada inicio, y nuevamente cada vez que se le indica a systemd que vuelva a cargar su configuración más adelante.
Este programa es un generador, un tipo de utilidad auxiliar cuyo trabajo es crear archivos de unidades de servicio sobre la marcha, en un tmpfs donde se encuentran tres más de esos nueve directorios (que están destinados a ser utilizados solo por generadores). systemd-sysv-generator genera las unidades de servicio que ejecutan la furgoneta Smoorenburg rc guiones de /etc/init.d, si no encuentra una unidad de servicio systemd nativa con ese nombre ya existente en las otras seis ubicaciones.
La gestión de servicios de systemd solo conoce las unidades de servicio. Estas unidades de servicio (re) generadas automáticamente están escritas para invocar la van Smoorenburg rc guiones. Tienen, entre otras cosas:
[Unit] SourcePath=/etc/init.d/wibble [Service] ExecStart=/etc/init.d/wibble start ExecStop=/etc/init.d/wibble stop
La sabiduría recibida es que el van Smoorenburg rc Los scripts deben tener un encabezado LSB y se ejecutan en paralelo sin respetar las prioridades impuestas por el /etc/rc?.d/ sistema. Esto es incorrecto en todos los puntos.
De hecho, no necesitan tener un encabezado LSB, y si no lo tienen systemd-sysv-generator puede reconocer los encabezados de comentarios de RedHat antiguos más limitados (description:, pidfile:, Etcétera). Además, en ausencia de un encabezado LSB, recurrirá al contenido del /etc/rc?.d granjas de enlaces simbólicos, leyendo las prioridades codificadas en los nombres de los enlaces y construyendo un antes / después de ordenarlos, serializando los servicios. No solo los encabezados LSB no son un requisito, y no solo ellos mismos codifican antes / después de los pedidos que serializan las cosas hasta cierto punto, el comportamiento de reserva en su completa ausencia es en realidad una operación significativamente no paralelizada.
La razón que /etc/rc3.d no parecía importar es que probablemente tenía ese script habilitado a través de otro /etc/rc?.d/ directorio. systemd-sysv-generator traduce estar incluido en cualquiera de /etc/rc2.d/, /etc/rc3.d/, y /etc/rc4.d/ en un nativo Wanted-By relación con systemd’s multi-user.target. Los niveles de ejecución son “obsoletos” en el mundo systemd, y puede olvidarse de ellos.
Otras lecturas
- systemd-sysv-generator. páginas de manual de systemd. Freedesktop.org.
- “Variables de entorno en procesos generados”.
systemd.exec. páginas de manual de systemd. Freedesktop.org. - https://unix.stackexchange.com/a/394191/5132
- https://unix.stackexchange.com/a/204075/5132
- https://unix.stackexchange.com/a/196014/5132
- https://unix.stackexchange.com/a/332797/5132
Systemd es compatible con versiones anteriores de los scripts de inicio de SysV. De acuerdo con LSB 3.1, el guión de inicio debe tener convenciones de comentarios informativos, definiendo cuándo el guión debe iniciarse / detenerse y qué se requiere para que el guión se inicie / se detenga. Esto es un ejemplo:
### BEGIN INIT INFO
# Provides: my-service
# Required-Start: $local_fs $network $remote_fs
# Required-Stop: $local_fs $network $remote_fs
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: start and stop service my-service
# Description: my-service blah blah ...
### END INIT INFO
Esta es una sección comentada que SysV ignora. Por otro lado, systemd lee esa información de dependencia y ejecuta esos scripts dependiendo de eso.
Pero hay un punto en el que systemd y SysV difieren en términos de scripts de inicio. SysV ejecuta los scripts en orden secuencial según su número en el nombre del archivo. Systemd no lo hace. Si se cumplen las dependencias, systemd ejecuta las secuencias de comandos inmediatamente, sin respetar la numeración de los nombres de las secuencias de comandos. Algunos de ellos probablemente fallarán debido al pedido. Hay muchas otras incompatibilidades que deben tenerse en cuenta.
Si hay scripts de inicio y archivos .service para el mismo servicio, systemd ejecutará ambos, tan pronto como se cumplan las dependencias (en el caso del script de inicio, las definidas en el encabezado LSB).
No se te olvide dar recomendación a esta reseña si te ayudó.