Como señaló Heemayl en el comentario, la página del manual responde a su pregunta. De la web:
Quiere =
Una versión más débil de Requiere =. Las unidades enumeradas en esta opción se iniciarán si la unidad de configuración es. Sin embargo, si las unidades enumeradas no se inician o no se pueden agregar a la transacción, esto no tiene ningún impacto en la validez de la transacción en su conjunto. Esta es la forma recomendada de conectar el arranque de una unidad al arranque de otra unidad.
Y requiere =:
Configura las dependencias de requisitos en otras unidades. Si esta unidad se activa, las unidades enumeradas aquí también se activarán. Si una de las otras unidades se desactiva o su activación falla, esta unidad se desactivará. Esta opción se puede especificar más de una vez o se pueden especificar varias unidades separadas por espacios en una opción, en cuyo caso se crearán dependencias de requisitos para todos los nombres enumerados. Tenga en cuenta que las dependencias de requisitos no influyen en el orden en que se inician o detienen los servicios. Esto tiene que configurarse independientemente con las opciones After = o Before =. Si una unidad foo.service requiere una unidad bar.service configurada con Requiere = y no se configura ningún pedido con After = o Before =, ambas unidades se iniciarán simultáneamente y sin demora entre ellas si foo.service está activado. A menudo,
Tenga en cuenta que este tipo de dependencia no implica que la otra unidad siempre tenga que estar en estado activo cuando esta unidad se esté ejecutando. Específicamente: las comprobaciones de condiciones que fallan (como ConditionPathExists =, ConditionPathExists =, ... - ver más abajo) no hacen que falle el trabajo de inicio de una unidad con una dependencia Requiere =. Además, algunos tipos de unidades pueden desactivarse por sí solos (por ejemplo, un proceso de servicio puede decidir salir limpiamente, o el usuario puede desconectar un dispositivo), que no se propaga a las unidades que tienen una dependencia Requiere =. Use el tipo de dependencia BindsTo = junto con After = para asegurarse de que una unidad nunca pueda estar en estado activo sin otra unidad específica también en estado activo (ver más abajo).
Su servicio solo se iniciará si se ha alcanzado el objetivo multiusuario (no sé qué sucede si intenta agregarlo a ese objetivo), y systemd intentará iniciar el servicio display-manager.service antes de su servicio . Si display-manager.service falla por cualquier razón, su servicio aún se iniciará (por lo que si realmente necesita el display-manager, úselo Requires=). Sin embargo, si no se alcanza el objetivo multiusuario , su servicio no se iniciará.
Cual es su servicio ¿Es un sistema de quiosco? Intuitivamente, supongo que desea agregar su servicio al multi-user.target (por lo que se inicia en el inicio), y hacer que dependa estrictamente del display-manager.service a través de Requires=display-manager.service. Pero eso es solo una adivinanza salvaje ahora.
La implementación de nuestro servidor utiliza LDAP que contiene todas las ID de usuario y mapas de montaje automático. Los directorios de inicio de los usuarios están montados en NFS, y los usuarios generalmente crean @reboot cronjobs con el código ejecutable en sus directorios de inicio. También usamos sssd para caché. Huelga decir que confiamos en poder proporcionar un orden de arranque determinista para que esta configuración funcione. Hemos desarrollado una configuración systemd muy sucinta, y hemos descubierto un matiz oscuro entre las opciones de la sección "quiere" y "requiere".
Si tiene un error en un servicio durante el arranque y hay otro servicio dependiente con "requiere" en ese servicio con "reinicio = siempre" establecido como una opción de servicio, ese servicio dependiente no se reiniciará. Sin embargo, si tiene "deseos" como opción, el servicio dependiente se reiniciará, como se esperaba.
man systemd.unitRespuestas:
Como señaló Heemayl en el comentario, la página del manual responde a su pregunta. De la web:
Y requiere =:
Desde la página de freedesktop.org
Su servicio solo se iniciará si se ha alcanzado el objetivo multiusuario (no sé qué sucede si intenta agregarlo a ese objetivo), y systemd intentará iniciar el servicio display-manager.service antes de su servicio . Si display-manager.service falla por cualquier razón, su servicio aún se iniciará (por lo que si realmente necesita el display-manager, úselo
Requires=). Sin embargo, si no se alcanza el objetivo multiusuario , su servicio no se iniciará.Cual es su servicio ¿Es un sistema de quiosco? Intuitivamente, supongo que desea agregar su servicio al multi-user.target (por lo que se inicia en el inicio), y hacer que dependa estrictamente del display-manager.service a través de
Requires=display-manager.service. Pero eso es solo una adivinanza salvaje ahora.fuente
La implementación de nuestro servidor utiliza LDAP que contiene todas las ID de usuario y mapas de montaje automático. Los directorios de inicio de los usuarios están montados en NFS, y los usuarios generalmente crean @reboot cronjobs con el código ejecutable en sus directorios de inicio. También usamos sssd para caché. Huelga decir que confiamos en poder proporcionar un orden de arranque determinista para que esta configuración funcione. Hemos desarrollado una configuración systemd muy sucinta, y hemos descubierto un matiz oscuro entre las opciones de la sección "quiere" y "requiere".
Si tiene un error en un servicio durante el arranque y hay otro servicio dependiente con "requiere" en ese servicio con "reinicio = siempre" establecido como una opción de servicio, ese servicio dependiente no se reiniciará. Sin embargo, si tiene "deseos" como opción, el servicio dependiente se reiniciará, como se esperaba.
fuente