¿Cuál es la diferencia entre "máscara systemctl" y "deshabilitar systemctl"?


35

Quiero mejorar el tiempo de arranque de mi Ubuntu GNOME 16.04 deshabilitando los servicios de plymouth al arrancar. He encontrado dos respuestas sobre cómo hacerlo en varios sitios web, a saber:

# systemctl disable plymouth-quit-wait.service 
# systemctl mask plymouth-quit-wait.service 

No puedo ejecutar ninguno de los anteriores a menos que sepa lo que hacen.


Respuestas:


52

Si un servicio es enabled, entonces hay un enlace simbólico en algún lugar de

/etc/systemd/system

a un archivo de unidad, con mayor frecuencia en algún lugar de

/lib/systemd/system

De manera útil, cuando prestas enableun servicio, las rutas completas del enlace y el destino creados se imprimirán en stdout.

Al deshabilitar el servicio, se elimina el enlace simbólico, por lo que el archivo de la unidad en sí no se ve afectado, pero el servicio no se carga en el próximo inicio, cuando se lee systemd /etc/systemd/system.

Sin embargo, se puede cargar un servicio deshabilitado y se iniciará si se inicia un servicio que depende de él ; enabley disablesolo configura el comportamiento de inicio automático para las unidades, y el estado se anula fácilmente.

Un servicio enmascarado es aquel cuyo archivo de unidad es un enlace simbólico /dev/null. Esto hace que sea "imposible" cargar el servicio, incluso si es requerido por otro servicio habilitado.

Cuando se maskpresta un servicio, se crea un enlace simbólico desde /etc/systemd/systemhasta /dev/null, dejando intacto el archivo de la unidad original en otro lugar. Cuando unmaskun servicio se elimina el enlace simbólico.

Sin embargo, he notado que estos comandos no siempre se cumplen.

Cuando intento enmascarar la mayoría de los servicios, falla:

$ sudo systemctl mask bluetooth.service
Failed to execute operation: Invalid argument

Por supuesto, primero detuve el servicio. @Anwar sugiere que el enmascaramiento solo es posible para servicios no críticos.

Desenmascarar un servicio enmascarado, a menos que yo mismo lo haya enmascarado, también falla (en silencio). Creo que esto se debe a que no hay un archivo unitario para el servicio en ninguna parte, excepto en forma de enlace simbólico /dev/null, esta vez en /lib/systemd/system:

$ file $(locate fuse.service)
/lib/systemd/system/fuse.service: symbolic link to /dev/null
$ sudo systemctl unmask fuse.service
$ systemctl status fuse
● fuse.service
   Loaded: masked (/dev/null; bad)
   Active: inactive (dead)

No soy el único que tiene este problema.

Para desenmascarar el servicio enmascarado x11-common, tuve que eliminar el enlace simbólico a /dev/nully sudo apt-get install --reinstall x11-common && sudo systemctl daemon-reload. Ahora, cuando lo consulto, systemctl status x11-commonveo que el servicio tiene un bonito círculo verde y está cargado y activo (salido) aunque no tiene un archivo unitario.

Para mayor referencia, este artículo sobre cómo usar Systemctl puede ser de alguna utilidad.


1
Hmm, ya entiendo systemctl status x11-common ● x11-common.service Loaded: masked (/dev/null; bad) Active: inactive (dead). ¿Es tan malo? Pero estoy en Debian, no Ubuntu. De todos modos, buena explicación. Gracias.
Faheem Mitha

@FaheemMitha No estoy seguro de que se necesite el servicio, mi sistema parece funcionar sin él. Sin embargo, no hay experiencia con Debian, ¡lo siento!
Zanna

17

Es bastante simple

  • systemctl start, systemctl stop: inicia (detiene) la unidad en cuestión inmediatamente ;
  • systemctl enable, systemctl disable: marca (desmarca) la unidad para el inicio automático en el momento del arranque (de una manera específica de la unidad, descrita en su [Install]sección);
  • systemctl mask, systemctl unmask: no permite (permite) todos y cualquier intento de iniciar la unidad en cuestión (ya sea manualmente o como dependencia de cualquier otra unidad, incluidas las dependencias del objetivo de inicio predeterminado). Tenga en cuenta que el marcado para el inicio automático en systemd se implementa al agregar una dependencia artificial del objetivo de inicio predeterminado a la unidad en cuestión, por lo que "máscara" también impide el inicio automático.

Ref .: systemctl (1) .

Más: Lennart Poettering (2011-03-02). "Los tres niveles de apagado" . systemd para administradores . 0pointer.de.



6

En breve,

  • disablehace que la unidad se deshabilite durante el arranque. Pero esa unidad se puede iniciar en cualquier momento después del arranque.

  • maskdesactiva la unidad por completo. No se puede iniciar sin desenmascarar. Eso implica automáticamente que fallará durante el arranque.


Tengo curiosidad: ¿hacer masky unmasktrabajar para usted? (¡Entiendo totalmente si no quieres probar!)
Zanna

1
@ Zanna sí. Eso funciona Lo he probado antes, nuevamente lo he probado ahora. Con postgresql@9.5-main.serviceservicio.
Anwar

Tengo que averiguar por qué no me funciona. Sé que no soy la única
Zanna

Puede ser que funcione para servicios no críticos. Todavía es nuevo, creo. por cierto, su respuesta fue más informativa. Fue útil
Anwar
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.