Por que alguns serviços systemd estão no estado "mascarado"?

42

Quando executo o comando sudo systemctl list-unit-files(acho que o sudo é opcional), recebo uma saída que mostra todos os serviços e seu estado.

Aqui está um trecho da minha 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
...

Eu me pergunto por que alguns serviços estão no estado "mascarado". Eu acho que isso significa, "isso é melhor do que 'desativar', porque o serviço não pode ser iniciado, nem manualmente nem pelo systemd".

Como posso obter mais informações sobre o estado de uma unidade de serviço?

Quem colocou as unidades em seus respectivos estados?

Eu tentei, por exemplo, sudo systemctl help dsmcad- que apenas traga a documentation = ...linha do arquivo de unidade./etc/systemd/system/dsmcad.service

Nota: Aqui eu sei exatamente o que é o serviço dsmcad e o que faz, eu mesmo o instalei. Estou mais interessado em uma solução geral.

systemd

— knb
fonte

47

maské uma versão mais forte do disable. O uso de disabletodos os links simbólicos do arquivo de unidade especificado é removido. Se o uso maskdas unidades estiver vinculado /dev/null. Isso será exibido se você marcar, por exemplo, por systemctl status halt.service. A vantagem maské impedir qualquer tipo de ativação, mesmo manual.

Cuidado: systemctl list-unit-filesestá listando o estado dos arquivos da unidade (estático, ativado, desativado, mascarado, indireto) e não tem nada a ver com o estado do serviço. Para dar uma olhada no uso dos serviçossystemctl list-units .

— Kellerspeicher
fonte

8

Por favor, também explique como remover o estado mascarado, se desejado.

— erikbwork

19

Existe um maske um unmaskcomando que pode ser usado com systemctl. Então apenas faça systemctl unmask name_of_service.service.

— Kellerspeicher

fazendo systemctl unmask name_of_service.serviceremovido completamente o meu arquivo de definição de serviço a partir /etc/systemd/system/, então agora eu preciso adicioná-lo de volta. Se torna-se mascarado de novo, eu vou ser preso em um oO laço

— Eldamir

11

Oi Eldamir, /etc/systemd/systemsão apenas links simbólicos de serviços. Você deve adicionar o *.servicearquivo /lib/systemd/systemde onde ele será vinculado /etc/systemd/systemse você for enableo serviço. maskestá criando um link para /dev/nulle unmaskestá removendo esse link /etc/systemd/systeme, obviamente, não faz diferença se alguém colocar um arquivo lá.

— Kellerspeicher

3

hostname.serviceé mascarado como redundante porque systemddefine o nome do host (de / etc / hostname) muito cedo durante a inicialização.

Esta configuração é fornecida pelo pacote systemd do 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

Da mesma forma, o Debian agora pode ser executado sem um script de shell haltno sistema, ele é tratado pelo systemd-shutdown (código fonte aqui ).

Se um serviço tiver sido mascarado manualmente, a máscara será instalada /etc/systemd/system.

Os serviços também são mascarados quando são removidos no Debian / Ubuntu . Não sei porque.

— sourcejedi
fonte

A ocultação versus remoção de serviços vem com a diferença de remover ou remover um pacote. No primeiro caso, os arquivos de configuração são mantidos e, portanto, pode ser potencialmente perigoso ativar um serviço por engano (como o arquivo de serviço ainda pode estar nos arquivos de configuração). Um pacote limpo também terá os arquivos de serviço removidos e não mascarados.

— Fiximan

0

Como você está solicitando informações sobre o estado mascarado, é importante mencionar que ele pode ser observado em um serviço que, após iniciado, teve as definições modificadas, recarrega (systemctl daemon-reload) e o novo estado NÃO está ok . Um exemplo fácil de entender é o seguinte cenário:

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

Portanto, o estado mascarado pode ser originado de definições de serviço incorretas. Portanto, o usuário pode induzir um estado não mascarado editando incorretamente o serviço.

Observação: não tenho certeza se isso acontece de propósito ou se é um bug simples (opção padrão), mas pode haver algumas informações interessantes para compartilhar

— Thiago Conrado
fonte