stdout에 기록하는 시스템 서비스가 있습니다. 거기에서 systemd는 STDOUT을 캡처하여 로그에 기록합니다.
저는 오류를 처리하기 위해 일반적인 관용구를 사용합니다. 여기서 echo
몇 가지 진단을 수행한 다음 0이 아닌 오류 코드로 종료합니다.
echo "my final error";
exit 1;
내 문제는 이 마지막 echo
줄이 일지에 나타나지만 내 "단위"와 제대로 연결되지 않는다는 것입니다. 을 보면 journalctl -o json-pretty
차이점이 무엇인지 알 수 있습니다. 최종 로그 레코드에 _SYSTEMD_CGROUP 및 _SYSTEMD_UNIT 속성이 누락되었습니다.
나는 무슨 일이 일어나고 있는지 경쟁 조건이라고 생각합니다. 나는 bash 스크립트가 journald
종료 라인에 들어가기 전에 완전한 처리를 기다리지 않는 것 같습니다. 따라서 exit
로그 항목 처리가 완료되기 전에 해당 줄에 도달합니다. 로깅이 전송된 로그를 찾아보았지만 장치가 더 이상 실행되지 않기 때문에 지금은 찾을 수 없습니다.journald
journald
unit
sleep 1
내 말이 맞다면 아마도 내 문 앞에 접두사를 붙여 이 문제를 해결할 수 있을 것입니다 exit 1
. 하지만 최종 로그 속성을 얻는 더 좋은 방법이 있습니까?
systemd
저는 버전 229를 사용하는 Ubuntu 16.04를 사용하고 있습니다.
답변1
@mark-stosberg, 이는 알려진 문제입니다.Journald는 SCM_CREDS와 경쟁하는 /proc로 인해 종료된 프로세스에서 들어오는 메시지를 해당 cgroup에 귀속시킬 수 없습니다.
해결 방법은 다음에서 찾을 수 있습니다.https://github.com/systemd/systemd/issues/2913#issuecomment-219702148
로깅 시스템이나 커널 로그 버퍼로 전송되는 로그 줄의 접두사로 프로세스 이름을 설정합니다.
그리고 달리다
journalctl _SYSTEMD_UNIT=unit + UNIT=unit + SYSLOG_IDENTIFIER=id
답변2
이것에 대해 좀 조사해 봤는데 그런 것 같아요.systemd의 알려진 문제, 끌어오기 요청이 있습니다..
수정 사항에는 서비스가 종료된 경우에도 해당 메타데이터를 계속 사용하여 마지막 몇 개의 로그를 올바르게 분류할 수 있도록 서비스의 메타데이터를 캐싱하는 작업이 포함됩니다.
그것도 고려된다CoreOS에서 버그 열기, systemd를 사용합니다.
이 버그는 다음과 같이 systemd freedesktop.org 버그 추적기에서도 추적됩니다.
추가 테스트를 통해 로그 소유권 상실 문제가 더욱 심각한 것으로 나타났습니다.사용자단위 - 이건 별개의 문제인 것 같아요. ~을 위한체계단위, 경쟁 조건은 비교적 사소하며 sleep 1;
서비스 스크립트에서 종료 전에 추가하면 인쇄된 마지막 로그와 종료 전 사이에 충분한 패딩을 추가하여 문제를 해결할 수 있습니다.