He leído lo que es multi-user.target y la documentación de systemd, que establece que multi-user.target es un objetivo especial. Además, muchos de los ejemplos de systemd contienen esa línea.
- ¿Por qué tantos servicios de ejemplo contienen esa línea?
- ¿Qué pasaría si no contuvieran WantedBy=multi-user.target?
- ¿Podría darme un ejemplo de cuándo sería realmente recomendable no incluir esa línea en una definición de archivo de servicio?
- Del mismo modo, ¿cuándo es una buena idea mantener esa línea?
Respuesta aceptada:
1.) multi-user.target es básicamente el equivalente más cercano al clásico SysVinit runlevel 3 que systemd posee. Cuando un systemd el sistema se inicia, systemd está tratando de hacer que el estado del sistema coincida con el estado especificado por default.target – que suele ser un alias para graphical.target o multi-user.target .
multi-user.target normalmente define un estado del sistema en el que se inician todos los servicios de red y el sistema aceptará inicios de sesión, pero no se inicia una GUI local. Este es el estado de sistema predeterminado típico para los sistemas de servidor, que pueden ser sistemas sin periféricos montados en rack en una sala de servidores remota.
graphical.target es otro posible alias para default.target . Normalmente se define como un superconjunto de multi-user.target :incluye todo el multi-user.target hace, además de la activación de un inicio de sesión GUI local. Algo así como el nivel de ejecución 5 en SysVinit clásico.
La línea WantedBy=multi-user.target en un servicio es esencialmente lo mismo que especificar "este servicio debe comenzar en los niveles de ejecución 3, 4 y 5" en los sistemas SysVinit:le dice a systemd que este servicio debe iniciarse como parte del inicio normal del sistema, ya sea que una GUI local esté activa o no.
Sin embargo, WantedBy es independiente del estado habilitado/deshabilitado:así que, en otro sentido, es una especie de "preajuste":determina bajo qué condiciones puede ocurrir el inicio automático, pero solo cuando el servicio está habilitado en primer lugar.
2.) si omite el WantedBy=multi-user.target línea y ningún otro servicio habilitado incluye un Requires=your.service o Wants=your.service en su definición de servicio, su servicio no se iniciará automáticamente.
systemd funciona en dependencias y en el momento del arranque, si nada Requires o Wants su servicio, no se iniciará incluso si el servicio está habilitado.
Claro, podrías editar tu default.target para agregar o eliminar Requires o Wants líneas para cualquier servicio que desee iniciar en el momento del arranque, pero para que pueda colocar un nuevo archivo de servicio en el sistema y hacer que funcione de forma predeterminada (lo que facilita mucho las cosas para los administradores de paquetes de software), systemd tiene el WantedBy y RequiredBy palabras clave que se pueden usar para insertar Wants y Requires -escriba las dependencias (respectivamente) desde "el otro extremo".
3.) Debe omitir la línea si no desea que el servicio se inicie automáticamente en el momento del arranque, o este servicio es parte de una cadena de dependencias que ha definido explícitamente.
Por ejemplo, podría estar refactorizando la aplicación de servidor A y, por alguna razón u otra, decidir dividir alguna funcionalidad opcional en un servicio B separado, para permitir al usuario la opción de no instalarla si no es necesaria. Luego podría hacer que el servicio B sea un service-B.rpm separado y defina B.service con WantedBy=A.service para hacer systemd inicie el servicio B automáticamente cada vez que se inicie el servicio A, pero solo cuando service-B.rpm está realmente instalado.
Tenga en cuenta que un Wants o WantedBy solo dice que el sistema debe iniciar un servicio siempre que también se inicie otro servicio u objetivo, pero no especifica nada sobre el orden de inicio/apagado. Si necesita que el servicio B ya se esté ejecutando cuando se inicie el servicio A, deberá agregar Before=A.service en el B.service para especificar explícitamente la dependencia del orden de inicio.
4.) Siempre que hagas desea que el servicio tenga la capacidad de iniciarse automáticamente en el momento del arranque, y no hay otras dependencias ya definidas.