systemd não pode encontrar o arquivo PID após a inicialização do wrapper YAJSW

Question

Eu tenho um script de inicialização systemd para um serviço de bifurcação (vamos chamá-lo de foo ) com base em YAJSW (ainda outro Wrapper de serviço Java) . A parte relevante do arquivo .service tem esta aparência:

ExecStart=/opt/foo/startup.sh
ExecStop=/opt/foo/shutdown.sh
Restart=always    
Type=forking
PIDFile=/opt/foo/wrapper.pid

O script startup.sh é responsável por iniciar o wrapper YAJSW. O arquivo de configuração YAJSW é configurado para que seu PID seja gravado em um arquivo durante a inicialização:

 wrapper.pidfile = /opt/foo/wrapper.pid

Desta forma, se o processo de wrapper morrer (por qualquer motivo), o systemd deve trazê-lo para cima, que é o comportamento desejado. Eu verifiquei que esta configuração funciona corretamente, mas uma linha estranha mostra no journalctl:

foo.service: PID file /opt/foo/wrapper.pid not readable (yet?) after start: No such file or directory

Estranhamente, o status do systemctl foo mostra o PID principal corretamente:

foo.service
...
Main PID: 12313 (java)

Estou fazendo algo errado ou isso é um bug em um dos componentes do software? Estou executando o Ubuntu 16.04.3 LTS, kernel versão 4.4.0, systemd versão 229.4. Qualquer ajuda será apreciada.

    

Answer 1

a forking service […] YAJSW (Yet Another Java Service Wrapper) […] ExecStart=/opt/foo/startup.sh […] ExecStop=/opt/foo/shutdown.sh […] PID is written to a file […]

Esse tipo de coisa é endêmica com Java e, na verdade, aparentemente com os sistemas Oracle em geral; mas também completamente desnecessário. Você não precisa que os Gerentes de Serviços da Poor Man, escritos em shell script ou Java, sejam executados sob um gerenciador de serviços real. Os arquivos PID são um mecanismo completamente perigoso e frágil. Você não precisa dos scripts startup.sh e shutdown.sh e eles acabam empurrando o processo de serviço real para baixo da árvore de processos para um fim sem problemas. Você não precisa de um arquivo de configuração YAJSW adicional. Você não precisa de um mecanismo de log complexo e idiossincrático baseado na saída padrão de buffer na memória.

Seu processo de serviço deve ser gerenciado diretamente pelo gerenciamento de serviço real e não usará o protocolo de prontidão de bifurcação systemd porque quase nada em estado selvagem realmente o utiliza. Não use scripts de shell do wrapper para executar os Gerenciadores de Serviços do Homem Pobre. Não use arquivos PID. Qualquer wrapper de script de shell deve carregar em cadeia, não fork. Seu arquivo de configuração é o arquivo da unidade de serviço systemd, e não algum arquivo de configuração outro . Seu mecanismo de registro é aquele que vem com o gerenciamento de serviços, que captura a saída padrão e o erro padrão e grava seus dados no arquivo.

Leitura adicional

• Jonathan de Boyne Pollard (2015). Envolvendo o Apache Tomcat em muitas camadas extras sem sentido Casa do Horror.
• Jonathan de Boyne Pollard (2015). A casa do sistema de terror . Respostas frequentemente dadas.
• Como evitar que o / usr / bin / env seja marcado nos logs do systemd como o executável
• configure o daemon java com o systemd
• link
• Jonathan de Boyne Pollard (2016). Não use logrotate ou newsyslog neste século. . Respostas frequentemente dadas.

Answer 2

Eu não diria que é um bug, mas um problema de complexidade. Atualmente, você tem essa cadeia apenas para iniciar e gerenciar seu aplicativo:

systemd -> startup.sh -> YAJSW -> actual app

Eu não sei exatamente o que o startup.sh e o YAJSW estão fazendo, mas seria desejável tentar simplificar o gerenciamento a ser feito:

systemd -> actual app

Então, se houver um problema com o gerenciamento, será muito mais fácil argumentar sobre o que está acontecendo.

Eu recomendo simplificar a situação maximizando o uso de systemd para gerenciamento e minimizando ou eliminando o que seus scripts e o YAJSW estão fazendo.