Início / unix / Perguntas / 519079
Accepted
Martin
Asked: 2019-05-16 05:24:35 +0800 CST

"systemctl start" não inicia uma unidade dependente reversa enquanto "systemctl restart" faz

  • 772

Eu tenho um fw.servicearquivo de unidade systemd que é um requisito para networking.service:

# systemctl show networking -p Requires
Requires=system.slice fw.service
#

Quando o networking.serviceestá no activeestado e eu executo systemctl stop fwe alguns segundos depois systemctl start fw, ele networking.servicefica no inactive (dead)estado. No entanto, quando o networking.serviceestá no activeestado e eu executo systemctl restart fw, o networking.servicetambém é reiniciado.

Esse é um comportamento esperado? Eu pensei que systemctl restarté basicamente systemctl stopseguido por systemctl starte, portanto systemctl start, também deve iniciar o networking.service.

systemd

1 respostas

  1. Best Answer

    restarté semelhante a stop+ start, mas não é idêntico. restartas tarefas são tratadas de forma diferente dentro do systemdgerenciador de serviços. Não é um simples recurso de conveniência na systemctlinterface.[*]

    Olhando para esse comportamento específico, ele não está documentado explicitamente na versão atual do man systemd.unit. (Pelo menos na minha instalação do systemd-239).

    O comportamento com stopé documentado. E o comportamento com starttambém é consistente com a documentação. O que não está explicitamente documentado é a propagação do restartpara a unidade que exigiu fw.service. No entanto, vejo uma dica sobre isso em outro tipo de dependência:

    PartOf=

    Configura dependências semelhantes a Requires=, mas limitadas a parada e reinicialização de unidades. Quando o systemd para ou reinicia as unidades listadas aqui, a ação é propagada para esta unidade. Observe que esta é uma dependência unidirecional — as alterações nesta unidade não afetam as unidades listadas.

    A dica é que se PartOf=for um subconjunto limitado de Requires=, então Requires=fará tudo o que PartOf=fizer. Portanto, isso inclui a propagação de reinicializações.

    Se networking.servicerealmente não quisesse ser interrompido na primeira etapa, você poderia substituir Requires=fw.servicepor Wants=fw.service. Mas suponho que Requires=foi usado deliberadamente, para tentar garantir que você nunca ative sua rede sem que suas regras de firewall estejam ativas.

    Você pode esperar que as reinicializações sejam sequenciadas de forma que networking.servicenunca seja ativada sem fw.servicetambém estar ativa, supondo que também seja definida After=fw.service ... Não confirmei que isso é o que realmente acontece. (Se esta é sua esperança, eu recomendaria verificá-la com base em alguma autoridade diferente desta resposta :-).

    Se você realmente quiser, eu acho que você pode colocar Wants=networking.serviceem fw.service, mesmo que networking.servicetenha Requires=fw.service. Isso é possível porque essas dependências não implicam em uma ordem específica. Acho que você só pode ter problemas com "loops de dependência" se tiver um conflito em suas dependências de ordenação - as configurações After=e .Before=

    [*] Por exemplo systemd-logind, destina -se a ser reinicializável e é organizado systemdpara manter certos arquivos críticos abertos durante a reinicialização. Mas se você apenas stoplogar, os arquivos abertos serão perdidos. (AFAIK reiniciar o systemd-logind ainda quebra todas as versões atuais do Xorg ou Wayland, mas você pode ver a ideia de que o systemdcódigo está tratando restartde maneira diferente :-P).

    • 3

relate perguntas