Início / unix / Perguntas / 516925
Accepted
peterh
Asked: 2019-05-04 02:24:17 +0800 CST

Como pedir ao systemd para não iniciar um serviço do sistema na inicialização?

  • 772

Não quero remover o serviço, só quero evitar que ele inicie na inicialização. Ainda preciso da opção de iniciá-lo manualmente mais tarde (com o systemctl start <service>comando).

Eu tentei usar systemctl disable <service>. Não funciona, porque remove o serviço.

Há outra possibilidade. Em seu arquivo de serviço,

[Install]
#WantedBy=multi-user.target

poderia ser comentada (e então, systemctl daemon-reload). Funciona no caso dos meus próprios serviços, porque seus arquivos de serviço foram escritos por mim.

No entanto, os arquivos de serviço pertencentes à distribuição estão em formato /lib/systemd/system. Os arquivos neste diretório são gerenciados pelo sistema operacional, ou seja, eles seriam substituídos por atualizações, outras partes do sistema podem supor que eles não foram modificados e assim por diante. Simplesmente editar arquivos do sistema fora do /etcé uma prática ruim, e eu não quero fazer isso. Não quero editar arquivos de configuração no meu arquivo /lib.

O que fazer?

systemd

2 respostas

  1. Best Answer

    systemctl disableé a maneira correta de fazer isso; ele ainda permite iniciar uma unidade manualmente, mesmo que não apareça na systemctl --allsaída do ' — para listar todas as unidades inicializáveis, você deve executar systemctl list-unit-files. Para tornar uma unidade não inicializável, você precisa maskdisso.

    $ sudo systemctl stop unbound
$ sudo systemctl status unbound
● unbound.service - Unbound DNS server
   Loaded: loaded (/lib/systemd/system/unbound.service; enabled; vendor preset: enabled)
   Active: inactive (dead) since Fri 2019-05-03 13:12:41 CEST; 5s ago
     Docs: man:unbound(8)
 Main PID: 5320 (code=exited, status=0/SUCCESS)

$ sudo systemctl disable unbound
$ sudo systemctl status unbound
● unbound.service - Unbound DNS server
   Loaded: loaded (/lib/systemd/system/unbound.service; disabled; vendor preset: enabled)
   Active: inactive (dead)
     Docs: man:unbound(8)

$ sudo systemctl start unbound
$ sudo systemctl status unbound
● unbound.service - Unbound DNS server
   Loaded: loaded (/lib/systemd/system/unbound.service; disabled; vendor preset: enabled)
   Active: active (running) since Fri 2019-05-03 13:13:14 CEST; 1s ago
     Docs: man:unbound(8)
  Process: 30513 ExecStartPre=/usr/lib/unbound/package-helper chroot_setup (code=exited, status=0/SUCCESS)
  Process: 30518 ExecStartPre=/usr/lib/unbound/package-helper root_trust_anchor_update (code=exited, status=0/SUCCESS)
 Main PID: 30525 (unbound)
    Tasks: 1 (limit: 4915)
   CGroup: /system.slice/unbound.service
           └─30525 /usr/sbin/unbound -d

    Se você realmente quiser, poderá substituir os serviços fornecidos pelo sistema definidos em /libadicionando arquivos em /etc, e alterar o destino desejado; systemctl edit yourunitfará a coisa certa: ele abre um editor, permitindo que você substitua apenas as configurações que lhe interessam, e ele armazenará o resultado no lugar certo, como um “snippet” de substituição. As atualizações feitas em configurações não substituídas nos serviços fornecidos pelo sistema ( por exemplo , por atualizações de pacotes) serão levadas em consideração de forma transparente.

    • 34

  2. Eu não esperava escrever uma resposta tão longa, mas você parece estar tentando coisas diferentes com o systemd, e suponho que você esteja mais interessado em seu mecanismo do que simplesmente digitar um comando mágico uma vez e esquecer que ele existia. E eu posso falar sobre o systemd por muito, muito mais tempo!

    EU.

    A resposta de Stephen Kitt é muito boa e exaustiva do ponto de vista da administração (e estou de bom grado votando nela), quando você , como administrador, deseja desabilitar um serviço de iniciar ou ser habilitado. Como a documentação do systemd v241 diz (consulte man 5 systemd.unit):

    Se um arquivo de unidade estiver vazio (ou seja, tiver o tamanho de arquivo 0) ou estiver vinculado a /dev/null, sua configuração não será carregada e aparecerá com um estado de carregamento "mascarado" e não poderá ser ativado. Use isso como uma maneira eficaz de desativar totalmente uma unidade, tornando impossível iniciá-la mesmo manualmente.

    systemctl maskfaz exatamente isso: cria um link simbólico com o mesmo nome da unidade /etce vincula o arquivo de serviço ao /dev/null. Como o systemd procura /etcprimeiro (a ordem é dada no mesmo manual, nas primeiras linhas) e encontra a unidade nomeada, ele descobre que a unidade está mascarada. Ele foi projetado para isso e, por favor, use-o se quiser impedir que um serviço seja ativado e iniciado. É a solução mais simples, de comando único, que sobrevive a uma reinicialização. Mantenha simples o que pode ser feito simples.

    II.

    No entanto, se você estiver projetando um conjunto de serviços que dependem uns dos outros, na função de um integrador de sistemas em vez de administrador, faz sentido declarar o serviço não inicializável ou imparável com o systemctlcomando, enquanto ainda permite outros mecanismos (sockets, dbus etc.) para iniciá-lo sob demanda. Para isso, o systemd possui configurações, também descritas no mesmo manual: RefuseManualStart=e RefuseManualStop=:

    Recebe um argumento booleano. Se for verdade, esta unidade só pode ser ativada ou desativada indiretamente. Nesse caso, a inicialização ou encerramento explícito solicitado pelo usuário é negado, porém, se for iniciado ou interrompido como dependência de outra unidade, a inicialização ou término será bem-sucedida. Este é principalmente um recurso de segurança para garantir que o usuário não ative acidentalmente unidades que não devem ser ativadas explicitamente e não desative acidentalmente unidades que não devem ser desativadas. Essas opções padrão para false.

    Você pode habilitar esse serviço, mas ele se recusará a iniciar systemctl start(ou parar, para a outra configuração), evitando um erro do operador.

    III.

    Um ponto a ser elaborado, sugerido pela sua ideia de comentar a [Install]seção no arquivo de serviço:

    [Install]
#WantedBy=multi-user.target

    Não faça isso se o serviço vier com o sistema , ou seja, quando o arquivo da unidade estiver em algum lugar abaixo da /libhierarquia! Uma atualização a substituirá silenciosamente ou solicitará que você intervenha manualmente para mesclar as alterações. systemd tem um mecanismo melhor para isso. Por convenção (para serviços do sistema), o diretório do systemd sob /etcé "seu", mas um sob /libpertence à distro.

    Se, por exemplo, você deseja remover a WantedBy=cláusula da [Install]seção, você deve usar o mecanismo apropriado do systemd para aplicar pequenos ajustes nos serviços: use o comando sudo systemctl edit servicename.service. O systemd abrirá um editor para você e, inicialmente, o arquivo estará vazio.

    A próxima propriedade útil do systemd que vem a calhar é que quando um valor de palavra-chave é uma lista (como WantedBy), atribuir a ele uma string vazia redefine a lista (há inconsistências em diferentes versões, mas na maioria das vezes funciona. No nosso caso faz). No editor, você adiciona duas linhas (isso é apenas uma elaboração do conceito que você tentou, mas não chegou a uma solução de trabalho; já sabemos que você conseguirá o que deseja mascarando) :

    [Install]
WantedBy=

    Isso redefine a WantedBylista para vazia. Se você quiser adicionar outra dependência, basta colocar outra linha com a mesma chave (outro WantedBy=another.service, em nosso exemplo mal concebido). O que realmente acontece nos bastidores, o systemd cria um arquivo de substituição/etc em , i. e. em seu diretório, proprietário da máquina, e promete nunca tocá-lo. O arquivo que o systemd cria é nomeado, assumindo o layout de diretório padrão, /etc/systemd/system/servicename.service.d/override.conf. Aqui a parte servicename.service é exatamente o nome da unidade que você está substituindo. systemd respeita todos os arquivos neste novo subdiretório, então pode haver mais do que apenas override.conf; apenas lembre-se de que eles serão aplicados em ordem lexicográfica de nomes, o mais baixo primeiro (como ls -1 *.conf | LC_ALL=C sortos mostraria).

    Embora não seja um mecanismo correto no seu caso, como Peter já respondeu em um comentário de acompanhamento, às vezes é útil quando você deseja, por exemplo, adicionar uma variável de ambiente ou até mesmo contornar um bug ¹, como

    $ cat /etc/systemd/system/systemd-remount-fs.service.d/override.conf
# Workaround for the systemd bug #14603: remount-fs and growfs@
# race, so that the latter may fail because the root fs is still
# readonly. This dependency ensures that the remount happens first.
[Unit]
[email protected]

    Você pode verificar se sua substituição foi incorporada à configuração da unidade usando systemctl show myunit.service . Sua saída é muito detalhada, então use grep:

    $ systemctl show systemd-remount-fs.service | grep ^Before=
Before=systemd-update-utmp.service [...] [email protected] [...]

    Não é o exemplo mais claro do mundo para ler, pois a linha é muito longa; Eu retirei a maior parte onde [...]estão os marcadores, mas você pode identificar [email protected]na lista. É uma boa prática sempre verificar se a alteração de configuração realmente chegou às configurações combinadas da unidade, mesmo antes de tentar iniciar/parar/inicializar/hibernar e outros cenários diferentes. Erros de ortografia acontecem.

    4.

    Naturalmente, você pode ajustar qualquer tipo de unidade, não apenas serviços: temporizadores, soquetes, montagens etc. Mesmo os arquivos de unidade gerados dinamicamente no /rundiretório respeitam esses ajustes. Por exemplo, embora no caso a seguir a /optmontagem seja montada usando seu /etc/fstab, o systemd gera uma unidade temporária opt.mountpara ele no diretório do sistema de arquivos na RAM/run/systemd/system . Esta unidade temporária reconhece perfeitamente um adicional Wants=especificado em/etc/systemd/system . E, a propósito, o serviço que ele quer é um exemplo de uso corretoRefuseManualStart de andRefuseManualStop : ele deve fazer seu trabalho apenas na /optmontagem e desmontagem do sistema de arquivos, e travaria ou cuspiaria erros se iniciado manualmente. Pior ainda, énão iniciaria logo após a /optmontagem do sistema de arquivos, se já tivesse sido iniciado manualmente!

    O serviço também mostra o padrão de "vinculação forte" especificando BindsTo=opt.mounte After=opt.mount. Citando o manual do systemd.unit(5), em "[UNIT] SECTION OPTIONS/BindsTo=", com minhas adições entre colchetes para tornar a linguagem mais digerível:

    Quando usado em conjunto com After= na mesma unidade[,] o comportamento de BindsTo= é ainda mais forte. Neste caso, a unidade [a qual esta unidade está] vinculada [deve] estar em estado ativo para que esta unidade também esteja [e permaneça] em estado ativo.

    A implicação aqui é que esta unidade é iniciada depois e parada antes opt.mountde ser parada, em um passo firme.

    * * *

    systemd é um sistema grande, poderoso e flexível, e, se você estiver procurando ajustar seu sistema da melhor maneira possível, leia sua documentação emman Web quando estiver entediado com outras coisas certamente é benéfico.

    ¹ O bug foi corrigido há mais de um ano, e a correção chegou à versão 245 do systemd, mas como estou reunindo uma frota de várias distribuições e, às vezes, acumulando VMs de imagens mais antigas, tenho que manter isso por um tempo. O Debian 10 tem um pré-fixo v241 do systemd; apenas o Debian 11 vem com v247. Os sistemas de produção são atualizados lentamente, então a solução é permanecer por mais alguns anos.

    • 14

relate perguntas