systemd-run --scope의 출력을 로그에 캡처합니다.

systemd-run --scope의 출력을 로그에 캡처합니다.

추적성, 책임성 등을 개선하기 위해 특정 애플리케이션을 systemd에서 감독하고 해당 출력을 로그에 수집하고 싶습니다. systemd-run의 서비스 모드를 사용할 때 이 모든 것이 자동으로 발생한다는 것을 알고 있지만 호출 환경에 대한 종속성으로 인해 때때로 이것이 불가능합니다.

systemd-run과 systemd-cat을 모두 사용해 보았지만 불행히도 유닛 메타데이터를 캡처하지 않습니다. 이론적으로는 env프로세스를 시작하기 전에 환경 변수를 파일에 덤프한 다음 systemd-run에 전달할 수 있다는 것을 알고 있지만 EnvironmentFile=이는 해킹처럼 보입니다. 필수 변수(예: 파일 설명자) 외에 실행 환경에 다른 데이터가 있는 경우에도 실패합니다. 그러나 이는 상대적으로 드문 요구 사항입니다. 쉘 파이프(가장 일반적인 유형의 공유 파일 설명자)는 일반적으로 셸 파이프로 대체될 수 있습니다. 임시로 명명된 파이프 또는 파일.

나는 해킹된 방법을 사용하는 것을 꺼리는 것이 아니라 "알려진 좋은" 대안이 있는지 궁금합니다.

편집: 댓글이 요청되었으므로 내가 찾고 있는 메타데이터 필드는 _SYSTEMD_UNIT, _SYSTEMD_SLICE등이며 _AUDIT_LOGINUID일반적으로 감독 프로세스를 위해 수집되는 _CAP_EFFECTIVE기타 메타데이터입니다 . Podman/conmon 컨테이너 로그를 살펴보면 sd_journal_sendv범위 단위 내에서 수동으로 생성되었음에도 불구하고 완전한 메타데이터가 있는 범위 단위를 사용하여 이것이 가능하다는 것을 알았습니다. 또한 소스 코드를 확인했는데 logger(1)동일한 기능을 사용하므로 로그가 존재하지 않는 systemd-run과 상관 관계를 설정하도록 하는 podman/conmon의 단위 설정에 뭔가가 있다고 가정합니다.

답변1

systemd-run --scope추가 실험을 통해 특정 엣지 케이스를 제외하고는 레이어링이 실제로 메타데이터를 올바르게 캡처한다는 사실을 발견했습니다 systemd-cat. 테스트 범위가 너무 좁아 해당 목표를 정확하게 달성했습니다.

자세히 말하면 저널이 들어오는 메시지를 처리하는 데 걸리는 시간과 systemd 가비지 수집이 종료된 후 범위 단위를 정리하는 데 걸리는 시간 사이에 경쟁 조건이 있을 수 있습니다.

테스트에서 두 도구 모두에 장기 실행 프로세스를 포함하거나 일회성 명령 끝에 절전 모드를 추가하면 로그 항목이 셀 메타데이터 등으로 적절하게 강화됩니다. 그러나 .pipe systemd-cat에 전달된 를 사용해야 하는 "exec" 형식은 작동하지 않습니다. --쉘을 열고 systemd-run --scope, 명령을 실행하고, 출력을 systemd-cat으로 파이프해 보았습니다. 위의 경쟁 조건을 피하기 위해 파이프라인 뒤에 sleep을 추가했지만 생성된 저널 항목에는 셀 메타데이터가 풍부하지 않았습니다.

관련 정보