☰

추가 읽기

tag-icon • tag-icon linux systemd logs systemd-journald
추가 읽기

왜 이런 일이 발생하는지 잘 모르겠습니다. 10초마다 임의의 텍스트를 표준 출력에 기록하는 테스트 서비스가 있습니다. 이것은 내 서비스 파일입니다 /etc/systemd/system/samplego.service.

[Unit]
Description=Sample go app
After=network.target

[Service]
SyslogIdentifier=my-samplego
ExecStart=/opt/samplego/samplego
Restart=on-failure

[Install]
WantedBy=multi-user.target

이것은 훌륭하게 작동하며 journalctl.

/etc/systemd/journald.conf그러나 문제 등의 설정을 변경하면 forwardtosyslog=yes애플리케이션이 로깅을 중지하고 systemctl restart systemd-journald문제가 발생할 때까지 업데이트가 표시되지 않습니다. 다시 시작한 후 모든 서비스를 다시 시작해야 합니까?journalctl -fsystemctl restart samplegojournald

답변1

1990년대 중반 daemontools의 주요 혁신 중 하나는증명 된 트랙 기록. 데몬 슈퍼바이저가 실행됩니다.둘보호자기본데몬과통나무악마. 파이프를 호출하기 전에 파이프를 열고 파이프의 쓰기 끝을 다음과 같이 제공합니다.기본데몬의 표준 출력과 파이프의 읽기 끝은 다음과 같은 역할을 합니다.통나무데몬의 표준 입력. 그것반품그 자체는 파이프의 양쪽 끝에 열린 파일 설명자를 유지합니다. 따라서 로그 데몬이 종료되거나 종료된 후 다시 시작되면 파이프에 기록된 로그 데이터가 보존되고 파이프가 닫히지 않으므로 새로 다시 시작한 로그 데몬 인스턴스에서 읽고 로깅할 수 있습니다.

systemd 디자이너는 이 디자인에서 배우지 않았습니다.

systemd생성된 서비스 프로세스(구성된 경우)가 소켓을 통해 표준 출력을 로깅 프로세스로 보내도록 준비합니다. 그러나 daemontools의 경우처럼 파이프를 열고 각 프로세스가 파이프의 적절한 끝을 상속하도록 배열하는 대신 스트림 소켓이 systemd사용됩니다 . 기본 프로세스는 클라이언트로 연결되고, 로그 프로세스는 서버로 수신됩니다.AF_LOCAL/run/systemd/journal/stdout

이는 데이터 연결에 상속된 파이프 의미가 아닌 클라이언트-서버 소켓 의미가 있음을 의미합니다. 서버가 끊기면 연결이 사라집니다. 버퍼링된 모든 로그 데이터가 손실되며 모든더 멀리메인 데몬이 쓴 데이터는 닫힌 소켓으로 들어가 손실됩니다. (이것이 systemd의 기본 설정이 true인 이유 중 하나입니다 IgnoreSIGPIPE. 닫힌 소켓에 로그 출력을 씁니다.반품커널이 로그에 쓰고 있는 데몬을 종료하려고 시도합니다. )

따라서 프로세스를 종료하면 systemd-journald프로세스 종료는 출력이 로깅 중인 모든 데몬에 대한 소켓 연결을 닫고 그 이후의 모든 출력은 손실됩니다. 이를 복구하고 기본 프로세스의 출력을 로그 프로세스에 다시 연결할 수 있는 방법은 없습니다. systemd다시 열 려면 모든 기본 프로세스를 다시 시작해야 합니다 .새로운(새로 생성된) 로그 서버에 대한 클라이언트 연결입니다.

systemd 사람들은 2016년에 해결책을 내놓았습니다. 여기에는 선택한 열린 파일 설명자를 프로세스 #1에 푸시하고 나중에 풀하는 프로세스 기능을 추가하는 작업이 포함됩니다. systemd-journald로깅 데몬 자체가 다시 시작될 때 클라이언트가 열린 상태로 유지되도록 로깅 중인 클라이언트에 대한 서버측 연결을 통해 이를 수행합니다.

이 메커니즘의 문제점은 보안을 유지하기 위해 더 많은 작업이 필요하고, 올해의 사건만으로도 입증되듯이 시스템을 갖춘 사람들은 보안 설계에 대한 좋은 기록을 갖고 있지 않다는 것입니다. 때문에 더 많은 작업이 필요합니다.WHO밀 수 있다무엇그리고얼마나#1을 처리할 파일 설명자를 열고얼마나 오랫동안액세스 제어 및 제한이 필요합니다. 그렇지 않으면 취약점이 많이 생길 수 있습니다. (daemontools 설계에서 서비스 관리자 프로세스 자체는 파일 설명자를 여는 개체이므로 하위 프로세스에 대해 열려 있는 파일 설명자를 절대적으로 제어할 수 있습니다. 속이거나 남용되거나 압도될 수 없습니다.)

Laurent Bercot의 s6에서는 s6-svscan기본 서비스와 로그 서비스 간의 파이프라인을 사용하여 일반적인 daemontools 작업이 수행됩니다. 또한 임의의 파일 설명자를 열어두는 메커니즘도 있습니다. 이는 systemd와 같이 프로세스 #1의 서비스 관리자 내에서 수퍼유저 권한으로 실행되는 코드를 통해 수행되지 않습니다. 이는 서비스 관리자와 별도로 실행되는 완전히 권한이 없는 프로세스에 의해 수행됩니다.

추가 읽기

관련 정보