Início / unix / Perguntas / 783769
Accepted
Braedon
Asked: 2024-09-20 08:17:51 +0800 CST

Onde o ciclo de ordenação do Systemd está ocorrendo?

  • 772

Tenho que unidades Systemd de um serviço e um soquete. O comportamento desejado é que quando eu iniciar o soquete o serviço será iniciado primeiro seguido pelo soquete e quando qualquer um for desativado ambos devem ser desativados. O serviço se vincula ao soquete antes que a unidade de soquete seja iniciada, e é por isso que o tenho como um serviço de notificação para que ele não relate como iniciado até que tenha o vínculo no soquete.

Aqui estão os arquivos das duas Unidades.

#rustyvxcan.service
[Unit]
Description=Docker VXCAN plugin Service
#PartOf=rustyvxcan.socket
    
Before=docker.service
After=network.target
    
[Service]
Type=notify
ExecStartPre=/usr/bin/mkdir -p /run/docker/plugins
ExecStart=/home/braedon/.cargo/bin/rustycan4docker
ExecReload=/bin/kill -HUP $MAINPID

[Install]
WantedBy=multi-user.target

#rustyvxcan.socket
[Unit]
Description=A network plugin for vxcan
Before=docker.service
AssertPathExists=/run/docker/plugins
Requires=rustyvxcan.service
After=rustyvxcan.service

[Socket]
ListenStream=/run/docker/plugins/rustyvxcan.sock
RemoveOnStop=True

[Install]
WantedBy=sockets.target

A mensagem de erro é a seguinte.

Sep 19 16:50:38 localhost systemd[1]: rustyvxcan.service: Found ordering cycle on rustyvxcan.socket/start
Sep 19 16:50:38 localhost systemd[1]: rustyvxcan.service: Found dependency on rustyvxcan.service/start
Sep 19 16:50:38 localhost systemd[1]: rustyvxcan.service: Unable to break cycle starting with rustyvxcan.service/start
Sep 19 16:55:09 localhost systemd[1]: rustyvxcan.socket: Found ordering cycle on rustyvxcan.service/start
Sep 19 16:55:09 localhost systemd[1]: rustyvxcan.socket: Found dependency on rustyvxcan.socket/start
Sep 19 16:55:09 localhost systemd[1]: rustyvxcan.socket: Unable to break cycle starting with rustyvxcan.socket/start

Pelos recursos, parece que significa que o ciclo está acontecendo apenas com esses dois arquivos e eu posso limpar o erro removendo a linha After do arquivo .socket, mas então eles inicializam simultaneamente e o executável para o serviço falha. Eu provavelmente poderia resolver isso simplesmente adicionando um sleep ao socket, mas não vejo informações de dependência suficientes aqui para causar um ciclo.

Eu tentei limpar /{lib,etc}/systemd/system do serviço e do arquivo de socket e reinstalar os que foram colados aqui só para ter certeza de que versões mais antigas não estavam em execução e, claro, executar systemctl daemon-reload regularmente enquanto o modificava. Mas não consigo entender por que especificar depois quebra o gráfico de dependências mesmo depois de remover as dependências do arquivo de serviço.

Onde está acontecendo o loop que estou perdendo?

systemd

1 respostas

  1. Best Answer

    O código que estou escrevendo gera um erro informando que o endereço do soquete já está em uso se o soquete for iniciado primeiro.

    Isso parece que você está tentando ligar bind()para si mesmo. O socket systemd realmente fará isso para você. É por isso que seu socket está falhando em vincular quando você força o serviço a iniciar primeiro.

    No caso de ListenStream=(uma conexão TCP ), o systemd chamará socket(), bind(), e listen()para você.

    Se você tiver Accept=no(padrão), quando os dados forem recebidos no socket, systemdiniciará seu processo e passará o FD daquele socket para você na variável de ambiente $LISTEN_FDS(veja sd_listen_fds(3) para detalhes). Este FD é o descritor de arquivo do socket de escuta . Você precisa chamar accept()para gerar um socket de conexão em cada conexão de entrada.

    Com Accept=yes, seu serviço deve ser uma instância (por exemplo, foo.sockete [email protected]). Nesse caso, o systemd chama accept()você e inicia seu ExecStart=uma vez por conexão, passando o FD do soquete de conexão . Você pode read(), select(), poll()de, ou write()para esse FD imediatamente.

    Eu costumo usar Accept=yes, StandardInput=sockete StandardOutput=socket. Então não preciso me preocupar com $LISTEN_FDS, TCP vs UDP. Eu apenas leio do stdin e escrevo no stdout. Nesse caso, qualquer coisa que eu queira registrar é escrita para stderro que vai para o diário.

    Se você quiser chamar socket(), bind()e você listen()mesmo accept(), não há necessidade de uma unidade systemd.socket.

    Em termos de uso...

    Geralmente só faz sentido habilitar/iniciar o socket. O socket cuidará de iniciar o serviço somente quando os dados forem recebidos. Sua briga com After=, Requires=, Assert*=, e ExecStartPre=mkdir...na verdade só torna sua vida mais difícil porque você está indo contra o uso pretendido. Eu faria isso:

    #rustyvxcan.service
[Unit]
Description=Docker VXCAN plugin Service

# Alternative to PartOf=: Just exit() on EOF (when read() returns 0).
PartOf=rustyvxcan.socket

[Service]
Type=notify
ExecStart=/home/braedon/.cargo/bin/rustycan4docker
ExecReload=/bin/kill -HUP $MAINPID

# Note that I deleted the [Install] section of the service
# It will be started by the socket, not by a target.

    #rustyvxcan.socket
[Unit]
Description=A network plugin for vxcan
Before=docker.service

[Socket]
ListenStream=/run/docker/plugins/rustyvxcan.sock
RemoveOnStop=True

[Install]
WantedBy=sockets.target

    Em vez disso, ExecStartPre=mkdireu usaria deploy uma tmpfiles.dconfiguração para garantir que o systemd gere esse caminho.

    # /etc/tmpfiles.d/rustyvxcan.conf
#Type Path                  Mode User Group Age Argument
d     /run/docker/plugins   0755 root root  -   -

    systemd-tmpfiles-setup.serviceusará este arquivo para garantir que o diretório seja criado quando você inicializar. Se você quiser que o arquivo seja criado agora (talvez na instalação), então systemd-tmpfiles --createfará isso para você.

    • 0

relate perguntas