Como consertar a atribuição de unidades das últimas linhas de log do systemd antes de sair?

6

Eu tenho um serviço systemd que registra no logout. A partir daí, o systemd captura o STDOUT e o grava no diário.

Eu uso um idioma comum para lidar com um erro em que eu echo alguns diagnósticos e, em seguida, saio com um código de erro diferente de zero:

echo "my final error";
exit 1;

Meu problema é que essa linha echo final chega ao diário, mas não está adequadamente associada à minha "unidade". Ao olhar para journalctl -o json-pretty , posso ver qual é a diferença. O log final não possui as propriedades _SYSTEMD_CGROUP e _SYSTEMD_UNIT.

O que eu acho que está acontecendo é uma espécie de condição de corrida. Eu suspeito que o script não espere que journald processe completamente o arquivo antes de passar para a linha de saída. Portanto, a linha exit é atingida antes que journald termine o processamento da entrada de log. journald tenta procurar o unit que enviou o registro, mas agora não consegue encontrá-lo, pois a unidade não está mais em execução.

Se eu estiver certo, provavelmente poderia resolver o problema colocando sleep 1 antes da declaração exit 1 , mas há uma maneira melhor de atribuir a propriedade de registros finais?

Estou usando o systemd versão 229 no Ubuntu 16.04.

    
por Mark Stosberg 22.06.2016 / 23:51

2 respostas

3

@ mark-stosberg, este é um problema conhecido: journald não pode atribuir mensagens recebidas de processos que saíram para o cgroup , devido a / proc vs corrida SCM_CREDS

Você pode encontrar uma solução alternativa lá: link

try SyslogIdentifier=

Sets the process name to prefix log lines sent to the logging system or the kernel log buffer with.

     

e execute journalctl _SYSTEMD_UNIT=unit + UNIT=unit + SYSLOG_IDENTIFIER=id

    
por 23.06.2016 / 04:55
2

Eu pesquisei isso e parece ser um problema conhecido com o systemd que há uma solicitação de pull .

A correção envolve o armazenamento em cache dos metadados do serviço, para que, mesmo que o serviço tenha saído, os metadados para ele ainda estejam disponíveis para categorizar adequadamente os últimos logs.

Ele também é considerado um bug de abertura no CoreOS , que usa o systemd.

O bug também é rastreado no rastreador de bugs systemd freedesktop.org em:

Testes adicionais descobriram que a questão da atribuição de logs ausentes é mais grave com as unidades usuário - suponho que seja um problema separado. Para unidades system , a condição de corrida é relativamente pequena e adicionar sleep 1; antes de sair no script de serviço pode adicionar preenchimento suficiente antes do último log impresso e da saída para solucionar o problema.

    
por 23.06.2016 / 04:58