Como um sinalizador de serviço systemd está pronto, para que outros serviços possam esperar que ele esteja pronto antes de iniciar?

Question

Eu tenho um monte de serviços (digamos C0 , C1 ,… C9 ) que só devem começar depois que um serviço S tiver concluído sua inicialização e estiver totalmente em execução e pronto para os outros serviços. Como faço para organizar isso com o systemd?

Em Solicitando serviços com ativação de caminho e destino no systemd , assume-se que o serviço S tem um mecanismo para escrevendo algum tipo de arquivo de bandeira. Suponha aqui, em contraste, que eu tenho controle total sobre o programa que o serviço S executa, e pode adicionar mecanismos systemd nele, se necessário.

    

Answer 1

Um não precisa necessariamente disso.

Se os serviços C precisarem esperar que S esteja pronto para que possam abrir uma conexão de soquete, então não é necessário fazer isso. Em vez disso, pode-se aproveitar a abertura inicial do soquete de escuta pelos gerentes de serviço.

Vários sistemas, incluindo s6 de Laurent Bercot , my nosh tools , e systemd, tem maneiras em que um socket de escuta pode ser aberto desde cedo, a primeira coisa na configuração do serviço. Todos eles envolvem algo diferente do programa de serviço que abre o soquete de escuta e o programa de serviço, quando invocado, recebendo o (s) soquete (s) de escuta como descritores de arquivo já abertos.

Com o systemd, especificamente, cria-se uma unidade de soquete que define o soquete de escuta. O systemd abre a unidade de soquete e a configura para que o subsistema de rede do kernel esteja atento a conexões; e passa para o serviço real como um descritor de arquivo aberto quando se trata de gerar o (s) processo (s) que manipula (m) conexões para o soquete. (Isso pode ser feito de duas maneiras, assim como inetd poderia, mas a discussão dos detalhes de Accept=true versus Accept=false services está além do escopo dessa resposta.)

O ponto importante é que não é necessário mais ordenação do que isso. O kernel agrupa as conexões do cliente em uma fila até que o programa de serviço seja inicializado e pronto para aceitá-las e conversar com os clientes.

Quando um faz, protocolos de prontidão são a coisa.

O systemd possui um conjunto de protocolos de prontidão que compreende serviço especificado por serviço com a configuração Type= na unidade de serviço. O protocolo de prontidão especial de interesse aqui é o protocolo de prontidão notify . Com ele, o systemd é informado para esperar mensagens do serviço e, quando o serviço está pronto, envia uma mensagem que sinaliza prontidão. O systemd atrasa a ativação dos outros serviços até que a prontidão seja sinalizada.

Usar isso envolve duas coisas:

• Modificando o código de S de forma que ele chame algo como a função notify_systemd() de Pierre-Yves Ritschard ou a função notify_socket() de Cameron T Norman.
• Configurando a unidade de serviço para o serviço com Type=notify e NotifyAccess=main .

A restrição NotifyAccess=main (que é o padrão) é porque o systemd precisa saber para ignorar mensagens de programas maliciosos (ou simplesmente defeituosos), porque qualquer processo no sistema pode enviar mensagens para o soquete de notificação do systemd.

Um usa o código de preferência de Pierre-Yves Ritschard ou Cameron T Norman porque não exclui a possibilidade de ter este mecanismo no UbuntuBSD, no Debian FreeBSD, no FreeBSD, no TrueOS, no OpenBSD e assim por diante; que o código fornecido pelos autores do sistema exclui.

Um trap para evitar é o programa systemd-notify . Ele tem vários problemas importantes, não menos do que é que as mensagens enviadas com ele podem acabar sendo jogadas fora do processado pelo systemd. O problema mais importante neste caso é que ele não é executado como o processo "principal" do serviço, portanto, é necessário abrir as notificações de prontidão do serviço S para cada processo no sistema com NotifyAccess=all .

Outra armadilha a ser evitada é pensar que o protocolo forking é mais simples. Não é. Fazê-lo corretamente envolve não bifurcar e sair do pai até que (por um lado) todos os threads de trabalho do programa estejam em execução. Isso não combina como a esmagadora maioria dos daemons que o garfo realmente bifurca.

Leitura adicional

• Jonathan de Boyne Pollard (2015). Problemas de protocolo de prontidão com os daemons do Unix . Respostas frequentemente dadas.
• Lennart Poettering (2010). sd_notify() . páginas de manual do systemd. Freedesktop.org.
• Lennart Poettering (2010). systemd-notify . páginas de manual do systemd. Freedesktop.org.
• Como gravar um arquivo de unidade de serviço do systemd para que ele aguarde até que uma interface específica seja ativada antes de iniciar?
• Adicionar informações de status à saída de status do systemd

Answer 2

Referindo-se à página de manual de systemd.service(5) , especificamente seção sobre Type = , cada tipo de serviço tem uma maneira diferente para o Systemd determinar que está pronto para oferecer funcionalidade a outros serviços:

• Se Type=simple , seus canais de comunicação devem ser instalados antes do daemon ser iniciado (por exemplo, sockets configurados pelo systemd, via ativação do soquete).

• Se Type=forking , o processo pai deverá sair quando a inicialização for concluída e todos os canais de comunicação estiverem configurados.

• Se Type=dbus , espera-se que o daemon adquira um nome no barramento D-Bus, ponto no qual o systemd continuará com o início das unidades de acompanhamento.

• Se Type=notify , espera-se que o daemon envie uma mensagem de notificação via sd_notify(3) ou uma chamada equivalente quando terminar de inicializar. O systemd continuará com as unidades de acompanhamento iniciais após essa mensagem de notificação ter sido enviada.

Para a última opção (enviando uma mensagem via sd_notify ), você pode usar o utilitário systemd-notify e lembre-se de conceder acesso a ele com NotifyAccess=all .

Dado que você tem controle sobre o serviço S , você está livre para escolher a melhor opção para o seu caso de uso, ou simplesmente o que é mais fácil de implementar.

    

Answer 3

assim:

S.serviço

[Unit]
Description=My main Service

[Service]
Type=notify
ExecStart=/usr/bin/myBinary

C0.service

[Unit]
Description=Dependent service number 0
PartOf=S.service

C1.service

[Unit]
Description=Dependent service number 1
PartOf=S.service

C9.service

[Unit]
Description=Dependent service number 9
PartOf=S.service

Onde / usr / bin / myBinary faz uma chamada sd_notify READY = 1 quando é inicializado está completo.

Dependendo de como você quer que a dependência se comporte, você pode usar PartOf, Requer ou BindsTo ou outros .