Asia, parte de este staff, nos ha hecho el favor de escribir este artículo ya que conoce a la perfección dicho tema.
Solución:
1.) multi-user.target es básicamente el equivalente más cercano del nivel de ejecución clásico 3 de SysVinit que systemd tiene. Cuando una systemd el sistema arranca, 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 del sistema predeterminado típico para los sistemas de servidor, que pueden ser sistemas sin cabeza montados en bastidor 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 lo multi-user.target hace, además de la activación de un inicio de sesión GUI local. Es algo así como el nivel de ejecución 5 en el clásico SysVinit.
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: indica systemd que este servicio debe iniciarse como parte del inicio normal del sistema, esté o no activa una GUI local.
Sin embargo, WantedBy está separado del estado habilitado / deshabilitado: en otro sentido, es una especie de “preestablecido”: 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, puedes editar tu default.target para agregar o eliminar Requires o Wants líneas para cualquier servicio que desee que se inicien 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 utilizar para insertar Wants y Requires-tipo dependencias (respectivamente) de “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, es posible que esté refactorizando la aplicación de servidor A y, por alguna razón u otra, decida dividir alguna funcionalidad opcional en un servicio B separado, para permitir al usuario la opción de no instalarlo si no es necesario. A continuación, puede hacer que el servicio B sea un service-B.rpmy definir B.service con WantedBy=A.service para hacer systemd iniciar el servicio B automáticamente siempre 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 cada vez que se inicia otro servicio o destino, pero no especifica nada en absoluto 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 archivo para especificar explícitamente la dependencia de la orden de inicio.
4.) En cualquier momento hacer desea que el servicio tenga la capacidad de iniciarse automáticamente en el momento del arranque, y no hay otras dependencias ya definidas.
Si quitas WantedBy=multi-user.target, luego systemctl enable your-example-here no hará nada (ruidosamente).
objetivo gráfico
Si instala systemd puro desde el origen, el “destino predeterminado” en el que arranca es graphical.target.
A partir de graphical.target empieza multi-user.target, además de las unidades necesarias para proporcionar una interfaz gráfica de usuario. Esta complejidad adicional se organizó en un intento de emular los “niveles de ejecución” heredados.
usted De Verdad debería ignorar / pasar por alto la emulación de “nivel de ejecución”; de todos modos no funciona correctamente. ¡Perdón! Supongo que la razón para enfatizar históricamente “gráficos” frente a “multiusuario” es que el software de gráficos 1) no es tan robusto y maduro como el resto del sistema y 2) requiere muchos recursos.
Normalmente, solo unas pocas unidades son específicas de graphical.target. Hay un único servicio para la propia GUI como gdm.target. Hay algunos servicios de apoyo que son principalmente utilizado por la GUI aquí también.
Editar: Google sugiere que si no tiene una GUI instalada, pero el “destino predeterminado” se ha dejado como graphical.target, es posible que systemd registre una advertencia. “No se puede agregar un trabajo de dependencia para la unidad display-manager.service, ignorando: La unidad display-manager.service no se pudo cargar: no existe tal archivo o directorio”. Queremos evitar ensuciar nuestros registros con advertencias innecesarias. Entonces, si no instaló una GUI, es bueno usar systemctl set-default multi-user. Aunque es posible que el sistema de instalación de su sistema operativo ya se haya ocupado de esto. Aparte de eso, estoy firmemente a favor de la apatía en este asunto :-).
sysinit.target
Algunos servicios y otros tipos de unidades están “involucrados en el arranque temprano”. Están definidos para empezar Before=sysinit.target – ya sea directa o indirectamente. La mayoría de los servicios solo se inician After=sysinit.target – este es automáticamente el caso, a menos que el servicio establezca DefaultDependencies=no.
multi-user.target
La mayoría de los servicios de ejemplo no se incluyen en ninguna de las categorías anteriores, por lo que los adjuntamos a multi-user.target. Esto incluye la mayoría de los servicios de red (por ejemplo, un servidor web), que son el servicio del sistema arquetípico.
servicios activados dinámicamente
Otra posibilidad que puede ver es una unidad de servicio que no comenzó automáticamente en el arranque. Entonces no necesitaría WantedBy=multi-user.target. En cambio, el servicio puede ser activado o “activado” por otra cosa.
Un ejemplo de esto es un servicio activado por dbus. Dbus puede configurarse para iniciar su servicio a pedido, cuando se realiza una llamada de dbus al servicio.
Para los servicios de red, puede utilizar los servicios activados por socket. Esto podría ser más fácil de encontrar detalles, porque toda la configuración está en unidades systemd. Por ejemplo sshd.socket o ssh.socket normalmente está disponible para activar [email protected] o [email protected]. Aunque, creo que es más común iniciar el servicio sshd en el momento del arranque.
Como siempre, lo anterior simplifica y omite detalles que no parecían ser necesarios.
Recuerda algo, que tienes concesión de valorar esta sección si te fue de ayuda.