☰

Como renomear um serviço systemd sem afetar o processo (sem parar/reiniciar)

tag-icon • tag-icon systemd
Como renomear um serviço systemd sem afetar o processo (sem parar/reiniciar)

Existem vários motivos para renomear um serviço systemd em produção. Por exemplo:

  • para diferenciá-lo melhor de um novo
  • porque seu chefe ordenou
  • por causa de scripts legados
  • ...

Supondo que um novo serviço genérico seja criado /etc/systemd/system/foo.service, habilitado e iniciado da seguinte forma: [1]

systemctl daemon-reload
systemctl enable --now foo

Em seguida, você pode querer renomeá-lo de foo.servicepara bar.servicesem afetar de forma alguma o processo relacionado.

Em circunstâncias normais, você pode fazer algo assim:

mv foo.service bar.service
systemctl daemon-reload
systemctl disable foo
systemctl enable  bar

Então você obtém:

  • systemctl status foo:running not-found disabled
  • systemctl status bar:not-running enabled

Então você pode querer corrigir com:

systemctl stop  foo
systemctl start bar

Ou com uma reinicialização. Porém em ambientes de produção isso não é viável já que você não deseja parar a aplicação para tal mudança. Além disso, as reinicializações são agendadas após meses ou anos. Ao mesmo tempo, é arriscado manter por muito tempo um serviço parado como baresse que não deve ser iniciado por engano antes de interromper a execução não encontrada foo.

Resumidamente. Que abordagem você usaria para renomear um serviço systemd em produção?

A condição ideal seria ter os dois serviços compatíveis com versões anteriores. Assim, parar footambém para bare vice-versa.

Responder1

Pode haver algum método melhor que eu não conheça, mas isso me vem à mente como uma solução alternativa que fornece principalmente o que você precisa até ter a chance de reiniciar o serviço:

  1. Crie um link simbólico com o novo nome desejado que aponta para o arquivo de serviço existente (e systemctl daemon-reload).
    Sistematrata links simbólicos para unidades como apelidosem vez de unidades separadas, o que significa que ambos os nomes agora se referirão à mesma unidade (mesmo status, mesmo tudo).
  2. Planeje realmente substituir o serviço durante a próxima janela de manutenção.

informação relacionada