Eu escrevi um script de inicialização LSB que pode gerenciar várias instâncias do meu daemon:
rcfoo startinicia todas as instâncias (que são encontradas em algum /etcarquivo de configuração), rcfoo stopinterrompe todas as instâncias, rcfoo statusexibe o status de todas as instâncias e rcfoo reloadrecarrega as atualizações do daemon com uma configuração alterada .
Primeiro, gostaria de saber como detectar as instâncias para trabalhar com algum [email protected]arquivo de unidade systemd. AFAIK Devo especificar todas as instâncias como foo@A, foo@Be assim por diante.
Em segundo lugar, meu script LSB pode relatar um status estendido, o que significa que pode exibir se um serviço reloadé necessário (e reloadrealmente otimiza para recarregar apenas os serviços que precisam). Como posso fazer um relatório de status personalizado? Eu acho que um script deve ser usado systemd-notifypara mensagens de status personalizadas.
Felizmente, minha extensão final para o script LSB, ou seja, manipular instâncias únicas adicionando single <instance>(como em rcfoo start single A), é compatÃvel com o systemd.
Então minha pergunta básica é a primeira.
Encontrei duas soluções possÃveis:
Escreva um "script wrapper" que aceite um parâmetro de instância e um parâmetro de comando. Em seguida, o script deve pesquisar se a instância solicitada é realmente encontrada no arquivo de configuração em
/etc. O script realmente fornecestart,stopereload, enquanto o PID do processo daemon é tratado pelo systemd viaPIDFile=.Além disso, escreva uma unidade de serviço como
[email protected]aquela que contém o script wrapper paraExecStart=,ExecStop=, etc. O nome da instância é representado por%ilá. O que não é tão bom é o fato de que você terá que saber os nomes das instâncias e, ao usar um inválido, o systemd cria uma instância não operacional que é reiniciada repetidamente (até ser limpa manualmente comsystemctl reset-failed). A coisa com reinicialização condicional não foi resolvida com essa abordagem. Então você fariasystemctl start foo@A.Alternativamente, você pode se livrar do script wrapper escrevendo um gerador que lê o arquivo de configuração e cria um arquivo de unidade de instância de serviço para cada instância encontrada. As linhas de comando usadas são montadas pelo gerador usando o arquivo de configuração. Comandos shell adicionais (por exemplo, para criar um diretório de tempo de execução ou aguardar a conclusão do fork do daemon) são adicionados pelo gerador via
ExecStartPre=eExecStartPost=.Existem alguns problemas não resolvidos, mas a comunidade systemd representada na lista de desenvolvimento não foi realmente útil: Eles me disseram que os geradores são um conceito avançado que eu não deveria usá-lo , não respondendo às minhas perguntas.
As coisas que faltam nesta resposta são: Como configurar um destino de sistema que inicia e interrompe todos os serviços? Eu pensei que teria um, mas falhou na inicialização (o arquivo de unidade gerado estava vazio por motivos desconhecidos).