¿Por qué algunos servicios systemd están en estado "enmascarado"?

43

Cuando ejecuto el comando sudo systemctl list-unit-files(creo que el sudo es opcional), obtengo una salida que muestra todos los servicios y su estado.

Aquí hay un fragmento de mi máquina:

UNIT FILE                                  STATE
...
debian-fixup.service                       static  
debug-shell.service                        disabled
display-manager.service                    enabled 
dns-clean.service                          enabled 
dsmcad.service                             enabled 
emergency.service                          static  
failsafe-x.service                         static  
friendly-recovery.service                  masked  
fuse.service                               masked  
gdm.service                                masked  
getty-static.service                       static  
getty@.service                             enabled 
gpsd.service                               indirect
gpsdctl@.service                           static  
gpu-manager.service                        enabled 
halt-local.service                         static  
halt.service                               masked  
hostname.service                           masked
...

Me pregunto por qué algunos servicios están en estado "enmascarado". Creo que esto significa, "esto es mejor que 'deshabilitar', porque el servicio no puede iniciarse, ni a mano ni por systemd".

¿Cómo puedo obtener más información sobre el estado de una unidad de servicio?

¿Quién ha puesto las unidades en su estado respectivo?

Intenté, por ejemplo, sudo systemctl help dsmcadque solo aparece la documentation = ...línea del archivo de la unidad./etc/systemd/system/dsmcad.service

Nota: Aquí sé exactamente qué es el servicio dsmcad y qué hace, lo instalé yo mismo. Estoy más interesado en una solución general.

systemd

— knb
fuente

48

maskes una versión más fuerte de disable. El uso de disabletodos los enlaces simbólicos del archivo especificado se eliminan unidad. Si utiliza masklas unidades se vinculará a /dev/null. Esto se mostrará si marca, por ejemplo, por systemctl status halt.service. La ventaja de maskes evitar cualquier tipo de activación, incluso manual.

Precaución: systemctl list-unit-filesmuestra el estado de los archivos de la unidad (estático, habilitado, deshabilitado, enmascarado, indirecto) y no tiene nada que ver con el estado del servicio. Para echar un vistazo a los servicios de uso systemctl list-units.

— Kellerspeicher
fuente

8

Explique también cómo eliminar el estado enmascarado, si lo desea.

— erikbwork

19

Hay un masky un unmaskcomando que se puede usar con systemctl. Así que solo hazlo systemctl unmask name_of_service.service.

— Kellerspeicher

esto systemctl unmask name_of_service.serviceeliminó por completo mi archivo de definición de servicio /etc/systemd/system/, por lo que ahora necesito agregarlo nuevamente. Si vuelve a enmascararse, estaré atrapado en un bucle oO

— Eldamir

1

Hola Eldamir, /etc/systemd/systemson solo enlaces simbólicos de servicios. Debe agregar el *.servicearchivo /lib/systemd/systemdesde donde se vinculará /etc/systemd/systemsi enableel servicio. maskestá creando un enlace /dev/nully unmaskestá eliminando este enlace /etc/systemd/systemy obviamente no hay diferencia si alguien coloca un archivo allí.

— Kellerspeicher

3

hostname.serviceestá enmascarado como redundante porque systemdestablece el nombre de host (desde / etc / hostname) muy temprano durante el inicio.

Esta configuración la proporciona el paquete systemian de Debian.

$ ls -l /lib/systemd/system/hostname.service
lrwxrwxrwx 1 root root 9 Apr  8 22:47 /lib/systemd/system/hostname.service -> /dev/null
$ dpkg-query --search /lib/systemd/system/hostname.service
systemd: /lib/systemd/system/hostname.service

De manera similar, Debian ahora puede ejecutarse sin un script de shell en haltel sistema, en su lugar se maneja mediante systemd-shutdown (código fuente aquí ).

Si un servicio se ha enmascarado manualmente, la máscara se instalará en su /etc/systemd/systemlugar.

Los servicios también se enmascaran cuando se eliminan en Debian / Ubuntu . No se porque.

— sourcejedi
fuente

El enmascaramiento frente a la eliminación de servicios viene con la diferencia de eliminar frente a la purga de un paquete. En el primer caso, los archivos de configuración se mantienen y, por lo tanto, podría ser potencialmente peligroso activar un servicio por error (ya que el archivo de servicio aún podría estar en los archivos de configuración). Un paquete purgado también tendrá los archivos de servicio eliminados y no enmascarados.

— Fiximan

0

Dado que está solicitando información sobre el estado enmascarado, es importante mencionar que se puede observar en un servicio que después de iniciado, modificó sus definiciones, recargó (systemctl daemon-reload) y el nuevo estado NO está bien . Un ejemplo sencillo para entenderlo es el siguiente escenario:

a) the service is running well (already started)
b) edit the service definition file and delete everything in its contents
c) reload
d) state masked will be observed too

Por lo tanto, el estado enmascarado puede originarse a partir de definiciones de servicio inadecuadas. Por lo tanto, el usuario puede inducir un estado desenmascarado editando incorrectamente el servicio.

Observación: no estoy seguro de si sucede a propósito o si es un error simple (opción predeterminada), pero puede ser una información interesante para compartir

— Thiago Conrado
fuente