Eu tenho um serviço systemd que faz login no stdout. A partir daí, o systemd captura STDOUT e grava-o no diário.
Eu uso uma expressão comum para lidar com um erro em que faço echoalguns diagnósticos e, em seguida, saio com um código de erro diferente de zero:
echo "my final error";
exit 1;
Meu problema é que esta echolinha final chega ao diário, mas não está devidamente associada à minha “unidade”. Olhando para journalctl -o json-pretty, posso ver qual é a diferença. A criação de log final não possui as propriedades _SYSTEMD_CGROUP e _SYSTEMD_UNIT.
O que acho que está acontecendo é uma espécie de condição de corrida. Suspeito que o script bash não espere journaldprocessar totalmente antes de passar para a linha de saída. Portanto, a exitlinha é alcançada antes de journaldterminar o processamento da entrada de log. journaldtenta procurar unitquem enviou o registro, mas agora não consegue encontrá-lo porque a unidade não está mais funcionando.
Se eu estiver certo, provavelmente poderia contornar o problema colocando sleep 1antes da minha exit 1declaração, mas existe uma maneira melhor de atribuir a propriedade dos logs finais?
Estou usando systemda versão 229 no Ubuntu 16.04.
Responder1
@mark-stosberg, este é um problema conhecido:journald não consegue atribuir mensagens recebidas de processos que saíram para seu cgroup, devido à corrida /proc vs SCM_CREDS
Você pode encontrar uma solução alternativa lá:https://github.com/systemd/systemd/issues/2913#issuecomment-219702148
tentar
SyslogIdentifier=Define o nome do processo para prefixar as linhas de log enviadas ao sistema de log ou ao buffer de log do kernel.
e corra
journalctl _SYSTEMD_UNIT=unit + UNIT=unit + SYSLOG_IDENTIFIER=id
Responder2
Eu pesquisei isso e parece ser umproblema conhecido com o systemd de que há uma solicitação pull para.
A correção envolve armazenar em cache os metadados do serviço, de modo que, mesmo que o serviço tenha sido encerrado, os metadados ainda estejam disponíveis para categorizar adequadamente os últimos logs.
Também é considerado umbug aberto no CoreOS, que usa o systemd.
O bug também é rastreado no rastreador de bugs do systemd freedesktop.org como:
Testes adicionais descobriram que o problema de falta de atribuição de log é mais grave comdo utilizadorunidades - presumo que seja um problema separado. Parasistemaunidades, a condição de corrida é relativamente pequena e adicionar sleep 1;pouco antes da saída no script de serviço pode adicionar preenchimento suficiente antes do último log impresso e da saída para solucionar o problema.