systemctl, como desmascarar

root@gcomputer:~# systemctl status x11-common
● x11-common.service
   Loaded: masked (/dev/null; bad)
   Active: inactive (dead)

Eu tentei systemctl unmask x11-commone systemctl unmask x11-common.servicemas isso não mudou nada.

Como desmascará-lo?

systemd

— Albert
fonte

Os comandos que você está usando estão corretos . Veja também o manual .

Parece que o unmaskcomando falha quando não há um arquivo de unidade existente no sistema que não seja o link simbólico para /dev/null. Se maskum serviço, em seguida, que cria um novo link simbólico para /dev/nullnos /etc/systemd/systemonde a aparência Systemd para arquivos de unidade para carregar na inicialização. Nesse caso, não há um arquivo de unidade real.

Outros parecem ter problemas semelhantes

x11-common.servicetambém foi mascarado no meu sistema. Você pode corrigi-lo assim:

Primeiro verifique se o arquivo da unidade é um link simbólico para /dev/null

file /lib/systemd/system/x11-common.service

deve retornar:

/lib/systemd/system/x11-common.service: symbolic link to /dev/null

nesse caso, exclua-o

sudo rm /lib/systemd/system/x11-common.service

Desde que você alterou um arquivo de unidade, é necessário executar o seguinte:

sudo systemctl daemon-reload

agora verifique o status:

systemctl status x11-common

se não estiver carregado e em execução (se o círculo ainda estiver vermelho), reinstale o pacote:

sudo apt-get install --reinstall x11-common

e recarregue o daemon novamente

sudo systemctl daemon-reload

e verifique o status mais uma vez

systemctl status x11-common

Agora está verde e em execução :) O serviço não possui um arquivo de unidade systemd, mas o systemd felizmente usa o script para ele /etc/init.d.

— Zanna
fonte

Ok, pergunta de acompanhamento: se ele foi mascarado no seu sistema, para que serve esse serviço? Parece que não é realmente necessário se estiver mascarado para nós dois.

— Albert

@ Albert [Veja aqui.] ( Askubuntu.com/questions/712276/… ) parece que o serviço funciona sem o arquivo de unidade systemd (ele tem um arquivo em /etc/init/...). Você pode fazer uma nova pergunta. O que fiz não fez diferença aparente, apenas o serviço é exibido como carregado, ativado, parado (está ativo na inicialização) (verde) em vez de morto mascarado carregado (vermelho). Eu deveria ler meus registros ...

— Zanna

se uma atualização para systemd vem por, o arquivo unidade for reinstalado, de modo que este não é realmente uma solução estrutural

— hbogert

@ hbogert isso acontece mesmo se não houver um arquivo de unidade além do link simbólico para /dev/null? Você está certo sobre a minha resposta. Eu chamaria esta solução uma solução alternativa para um ... confundindo comportamento ... de systemd

— Zanna

Você poderia descrever sua primeira frase em termos de arquivos exatos que importam neste caso (porque eu realmente não entendo o cenário que você descreve)?

— Hbogert 17/07

Pode ser que seu serviço tenha um arquivo de substituição vazio, como este:

● redis-server.service - Armazenamento avançado de valores-chave Carregado: carregado (/lib/systemd/system/redis-server.service; mascarado; predefinição de fornecedor: ativado) Drop-In: / etc / systemd / system / redis-server .service.d └─limit.conf

Verifique se limit.conf é um arquivo vazio. Se for, remova-o. Em seguida, o serviço deve ser desmascarado.

— Erik Hensema
fonte

Siga os passos abaixo:

systemctl edit systemd-hostnamed

Adicione as 2 linhas abaixo e saia do editor (não esqueça de salvar quando solicitado):
```
[Service]
PrivateNetwork=no
```
Isso criará um arquivo override.conf com as 2 linhas acima no diretório:
```
/etc/systemd/system/systemd-hostnamed.service.d/
```
O sistema de atualização:
```
systemctl daemon-reload
```
Em seguida, reinicie o serviço:
```
systemctl restart systemd-hostnamed
```

Agora você deve poder executar hostnamectlsem travar.

— Hossein
fonte