Qual é a diferença entre "máscara systemctl" e "systemctl disable"?

Desejo melhorar o tempo de inicialização do meu Ubuntu GNOME 16.04 desativando os serviços plymouth ao inicializar. Eu encontrei duas respostas sobre como fazê-lo em vários sites, a saber:

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

Não posso executar nenhum dos itens acima, a menos que eu saiba o que eles fazem.

Se um serviço for enabled, existe um link simbólico em algum lugar

/etc/systemd/system

para um arquivo de unidade, geralmente em algum lugar

/lib/systemd/system

Ajuda, quando você enablepresta um serviço, os caminhos completos do link e destino criados serão impressos em stdout.

Desativar o serviço exclui o link simbólico, para que o arquivo da unidade em si não seja afetado, mas o serviço não seja carregado na próxima inicialização, quando o systemd ler /etc/systemd/system.

No entanto, um serviço desabilitado pode ser carregado e será iniciado se um serviço que depende dele for iniciado ; enablee disableapenas configure o comportamento de inicialização automática para unidades, e o estado é facilmente substituído.

Um serviço mascarado é aquele cujo arquivo de unidade é um link simbólico para /dev/null. Isso torna "impossível" carregar o serviço, mesmo que seja exigido por outro serviço ativado.

Quando você é maskum serviço, um link simbólico é criado de /etc/systemd/systempara /dev/null, deixando o arquivo da unidade original em outro local intocado. Quando você é unmaskum serviço, o link simbólico é excluído.

No entanto, notei que esses comandos nem sempre são respeitados.

Quando tento mascarar a maioria dos serviços, ele falha:

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

Claro, parei o serviço primeiro. @Anwar sugere que o mascaramento só é possível para serviços não críticos.

Desmascarar um serviço mascarado, a menos que eu mesmo tenha mascarado, também falha (silenciosamente). Eu acredito que isso ocorre porque não há arquivo de unidade para o serviço em qualquer lugar, exceto na forma de um link simbólico para /dev/null, desta vez em /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)

Eu não sou o único com esse problema

Para realmente desmascarar o serviço mascarado x11-common, tive que excluir o link simbólico para /dev/nulle sudo apt-get install --reinstall x11-common && sudo systemctl daemon-reload. Agora, quando a consulta, systemctl status x11-commonvejo que o serviço possui um belo círculo verde e está carregado e ativo (encerrado), embora não tenha um arquivo de unidade.

Para referência adicional, este artigo sobre Como usar o Systemctl pode ser útil.

É bem simples.

• systemctl start, systemctl stop: inicia (para) a unidade em questão imediatamente ;
• systemctl enable, systemctl disable: Marcas (Desmarca) da unidade de arranque automático no momento do arranque (de um modo específico do aparelho, descrito na sua [Install]secção);
• systemctl mask, systemctl unmask: proíbe (permite) todas e quaisquer tentativas de iniciar a unidade em questão (manualmente ou como uma dependência de qualquer outra unidade, incluindo as dependências do destino de inicialização padrão). Observe que a marcação para inicialização automática no systemd é implementada adicionando uma dependência artificial do destino de inicialização padrão à unidade em questão; portanto, "mascarar" também não permite a inicialização automática.

Ref .: systemctl (1) .

Mais: Lennart Poettering (02/03/2011). "Os três níveis de folga" . systemd para administradores . 0pointer.de.

Em resumo,

• disabledesativa a unidade durante a inicialização. Mas essa unidade pode ser iniciada a qualquer momento após a inicialização.

• maskdesativa completamente a unidade. Não pode ser iniciado sem desmascarar. Isso implica automaticamente que falhará durante a inicialização.