systemd+rsyslog 호스트에서 `/dev/log`를 복원하는 방법은 무엇입니까?

Question 1

Google은 이 문제에 대해 별로 도움이 되지 않기 때문에 직접 질문하고 대답하는 것이 좋습니다.

일반적으로 를 사용하면 rsyslogd모듈은 imuxsock소켓 자체를 생성하고 이전 항목을 생성하기 전에 연결을 해제합니다. 중지된 /dev/log경우 rsyslogd(잘못된 구성 및 재시작 실패로 인해)rsyslogd 삭제 /dev/log.

그러나 제공된 rsyslog는 RHEL7와 함께 사용될 것으로 예상되며 systemd이 모듈은 실제로 소켓을 imuxsock열고 삭제합니다 . /run/systemd/journal/syslog동시에 트리거된 /dev/log시스템 서비스 파일에 의해 장치가 생성됩니다.systemd-journald.socketjournald

분명히 $imjournal다음은 모듈 사용 여부에 관계없이 작동합니다.

요약하면, /dev/log사라지는 경우:

systemd-journald.socket을 다시 시작합니다.
```
systemctl restart systemd-journald.socket
```
그런 다음 rsyslogd를 다시 시작하십시오.
```
systemctl start rsyslogd
```

업데이트: 소켓이 이미 실행 중인 경우 소켓을 다시 삭제할 수 있다고 생각합니다 systemctl restart rsyslogd.rsyslogd

Answer

Google은 이 문제에 대해 별로 도움이 되지 않기 때문에 직접 질문하고 대답하는 것이 좋습니다.

일반적으로 를 사용하면 rsyslogd모듈은 imuxsock소켓 자체를 생성하고 이전 항목을 생성하기 전에 연결을 해제합니다. 중지된 /dev/log경우 rsyslogd(잘못된 구성 및 재시작 실패로 인해)rsyslogd 삭제 /dev/log.

그러나 제공된 rsyslog는 RHEL7와 함께 사용될 것으로 예상되며 systemd이 모듈은 실제로 소켓을 imuxsock열고 삭제합니다 . /run/systemd/journal/syslog동시에 트리거된 /dev/log시스템 서비스 파일에 의해 장치가 생성됩니다.systemd-journald.socketjournald

분명히 $imjournal다음은 모듈 사용 여부에 관계없이 작동합니다.

요약하면, /dev/log사라지는 경우:

systemd-journald.socket을 다시 시작합니다.
```
systemctl restart systemd-journald.socket
```
그런 다음 rsyslogd를 다시 시작하십시오.
```
systemctl start rsyslogd
```

업데이트: 소켓이 이미 실행 중인 경우 소켓을 다시 삭제할 수 있다고 생각합니다 systemctl restart rsyslogd.rsyslogd

Question 2

이 systemctl restart systemd-journald.socket && systemctl restart rsyslog솔루션은 Ubuntu 16.04에서 작동하지 않았습니다.

/dev/log대신 다음 심볼릭 링크를 다시 만들어야 했습니다 /run/systemd/journal/dev-log.

ln -s /run/systemd/journal/dev-log /dev/log

Answer

이 systemctl restart systemd-journald.socket && systemctl restart rsyslog솔루션은 Ubuntu 16.04에서 작동하지 않았습니다.

/dev/log대신 다음 심볼릭 링크를 다시 만들어야 했습니다 /run/systemd/journal/dev-log.

ln -s /run/systemd/journal/dev-log /dev/log

Question 3

systemd와 rsyslog가 정확히 어떻게 작동하는지 잘 모르겠지만 한동안 이것저것 만지작거리다가 /dev/log사라진 이유와 복원 방법을 알아냈습니다.

이전 답변에서 언급했듯이 Rsyslog에 imuxsock 모듈을 설정하면 /dev/log서비스가 시작될 때 자체적으로 소켓이 생성 되고 /etc/rsyslog.conf서비스가 중지되면 소켓이 삭제됩니다. ~에 따르면imuxsock 문서, 소켓이 systemd를 통해 전달되지 않으면 rsyslog는 소켓만 삭제합니다. 이 경우 /dev/log소켓은 systemd가 아닌 rsyslog를 통해 전달되므로 서비스가 중지되면 소켓이 삭제됩니다.

기본적으로(저는 Fedora 36을 사용하고 있습니다) rsyslog는 imuxsock 모듈을 사용하지만 "SysSock.Use=off" 매개변수를 사용합니다. 이렇게 하면 rsyslog는 syslog 소켓( /dev/log)을 소켓으로 사용하지 않으므로 생성되지 않습니다 . ( ) /dev/log에서 이 구성을 사용하면 rsyslog에 아무 것도 기록되지 않습니다.module(load="imuxsock" SysSock.use="off")/etc/rsyslog.conf

그러나 기본적으로 로드되는 또 다른 모듈이 있는데, 바로 imjournal 모듈입니다. 이렇게 하면 rsyslog에 systemd 로그에 대한 액세스 권한이 부여됩니다. 내가 이해하는 한, rsyslog는 소켓을 생성하지 않지만 /dev/logsystemd-journal-dev-log.socket은 생성합니다. 소켓 /dev/log은 에 심볼릭 링크됩니다 /run/systemd/journal/dev-log. 사용되더라도 module(load="imuxsock" SysSock.use="off")rsyslog는 systemd 로그에서 데이터를 가져오기 때문에 계속 활동을 기록합니다. 이제 /dev/log -> /run/systemd/journal/dev-log생성되었으므로 소켓이 systemd를 통해 전달되었기 때문에 rsyslog는 이를 삭제하지 않습니다.

내 시도에 따르면 /dev/log나중에 "SysSock.use=off" 매개변수가 추가되거나 주석 처리가 해제되었기 때문에 사라질 수 있습니다 /etc/rsyslog.conf(imjournal 모듈이 로드된 경우에도 마찬가지입니다). 이는 rsyslog에 /dev/log.

틀림없이 imjournal 모듈을 다시 추가하고 서비스를 다시 시작하면 문제가 해결될 것입니다. 그러나 혼란스러운 부분은 이것이 작동하지 않고 /dev/log -> /run/systemd/journal/dev-log찾을 수 없다는 것입니다. 이는 systemd-journald-dev-log.socket 서비스가 소켓 /dev/log누락을 인식하지 못하기 때문입니다. 따라서 이 서비스를 다시 시작하면 소켓 손실이 발생하고 systemd-journald.socket을 다시 시작하면 문제가 해결됩니다. systemd-journald-dev-log.socket 서비스를 다시 시작해도 작동할지 확실하지 않지만 소켓이 /dev/log다시 시작됩니다.

요약하자면, 소켓을 복구하려면 다음을 수행하십시오 /dev/log.

다음 사항이 있는지 확인하세요 /etc/rsyslog.conf.
- module(load="imuxsock" SysSock.use="off")
- module(load="imjournal" StateFile="imjournal.state")
rsyslog 다시 시작
```
# systemctl restart rsyslog
```
systemd-journald-dev-log.socket을 다시 시작합니다("Job failed. 자세한 내용은 "journalctl -xe"를 참조하세요." 경고가 표시될 수 있지만 중지하고 즉시 시작하므로 괜찮다고 생각합니다).
```
# systemctl restart systemd-journald-dev-log.socket
```

systemd-journald.socket 다시 시작

# systemctl restart systemd-journald.socket

참고 1: 제가 아는 한 이는 RHEL 시스템에만 적용됩니다. Debian 또는 Ubuntu 기반 시스템에는 이 문제가 없거나 다른 해결 방법이 있을 수 있습니다.

참고 2: 길고 혼란스러운 답변에 대해 사과드립니다. 처음 가보는 곳이라 아직은 초보입니다 :D

Answer

systemd와 rsyslog가 정확히 어떻게 작동하는지 잘 모르겠지만 한동안 이것저것 만지작거리다가 /dev/log사라진 이유와 복원 방법을 알아냈습니다.

이전 답변에서 언급했듯이 Rsyslog에 imuxsock 모듈을 설정하면 /dev/log서비스가 시작될 때 자체적으로 소켓이 생성 되고 /etc/rsyslog.conf서비스가 중지되면 소켓이 삭제됩니다. ~에 따르면imuxsock 문서, 소켓이 systemd를 통해 전달되지 않으면 rsyslog는 소켓만 삭제합니다. 이 경우 /dev/log소켓은 systemd가 아닌 rsyslog를 통해 전달되므로 서비스가 중지되면 소켓이 삭제됩니다.

기본적으로(저는 Fedora 36을 사용하고 있습니다) rsyslog는 imuxsock 모듈을 사용하지만 "SysSock.Use=off" 매개변수를 사용합니다. 이렇게 하면 rsyslog는 syslog 소켓( /dev/log)을 소켓으로 사용하지 않으므로 생성되지 않습니다 . ( ) /dev/log에서 이 구성을 사용하면 rsyslog에 아무 것도 기록되지 않습니다.module(load="imuxsock" SysSock.use="off")/etc/rsyslog.conf

그러나 기본적으로 로드되는 또 다른 모듈이 있는데, 바로 imjournal 모듈입니다. 이렇게 하면 rsyslog에 systemd 로그에 대한 액세스 권한이 부여됩니다. 내가 이해하는 한, rsyslog는 소켓을 생성하지 않지만 /dev/logsystemd-journal-dev-log.socket은 생성합니다. 소켓 /dev/log은 에 심볼릭 링크됩니다 /run/systemd/journal/dev-log. 사용되더라도 module(load="imuxsock" SysSock.use="off")rsyslog는 systemd 로그에서 데이터를 가져오기 때문에 계속 활동을 기록합니다. 이제 /dev/log -> /run/systemd/journal/dev-log생성되었으므로 소켓이 systemd를 통해 전달되었기 때문에 rsyslog는 이를 삭제하지 않습니다.

내 시도에 따르면 /dev/log나중에 "SysSock.use=off" 매개변수가 추가되거나 주석 처리가 해제되었기 때문에 사라질 수 있습니다 /etc/rsyslog.conf(imjournal 모듈이 로드된 경우에도 마찬가지입니다). 이는 rsyslog에 /dev/log.

틀림없이 imjournal 모듈을 다시 추가하고 서비스를 다시 시작하면 문제가 해결될 것입니다. 그러나 혼란스러운 부분은 이것이 작동하지 않고 /dev/log -> /run/systemd/journal/dev-log찾을 수 없다는 것입니다. 이는 systemd-journald-dev-log.socket 서비스가 소켓 /dev/log누락을 인식하지 못하기 때문입니다. 따라서 이 서비스를 다시 시작하면 소켓 손실이 발생하고 systemd-journald.socket을 다시 시작하면 문제가 해결됩니다. systemd-journald-dev-log.socket 서비스를 다시 시작해도 작동할지 확실하지 않지만 소켓이 /dev/log다시 시작됩니다.

요약하자면, 소켓을 복구하려면 다음을 수행하십시오 /dev/log.

다음 사항이 있는지 확인하세요 /etc/rsyslog.conf.
- module(load="imuxsock" SysSock.use="off")
- module(load="imjournal" StateFile="imjournal.state")
rsyslog 다시 시작
```
# systemctl restart rsyslog
```
systemd-journald-dev-log.socket을 다시 시작합니다("Job failed. 자세한 내용은 "journalctl -xe"를 참조하세요." 경고가 표시될 수 있지만 중지하고 즉시 시작하므로 괜찮다고 생각합니다).
```
# systemctl restart systemd-journald-dev-log.socket
```

systemd-journald.socket 다시 시작

# systemctl restart systemd-journald.socket

참고 1: 제가 아는 한 이는 RHEL 시스템에만 적용됩니다. Debian 또는 Ubuntu 기반 시스템에는 이 문제가 없거나 다른 해결 방법이 있을 수 있습니다.

참고 2: 길고 혼란스러운 답변에 대해 사과드립니다. 처음 가보는 곳이라 아직은 초보입니다 :D

Question 4

나에게 이것은 rsyslog에 사용되는 imuxsock 모듈이 systemd와 어떻게 작동하는지에 대한 질문으로 끝났습니다.

내부에imuxsock 문서이 모듈이 systemd에서 어떻게 작동하는지 설명합니다. 1단계에서 문제를 발견했습니다.

1단계: 시스템 소켓 이름 선택

사용자가 SysSock.Use="off" 설정을 명시적으로 선택하지 않으면 기본 수신기 소켓("syslog 소켓" 또는 간단히 "시스템 소켓"이라고도 함) 이름이 /dev/log로 설정됩니다. 그렇지 않고 사용자가 SysSock.Use="off"를 명시적으로 설정한 경우 rsyslog는 /dev/log 또는 SysSock.Name 매개 변수로 정의된 소켓을 수신하지 않으며 이 섹션의 나머지 부분은 적용되지 않습니다.

사용자가 sysSock.Name="/path/to/custom/socket"을 지정하고 SysSock.Use="off"를 명시적으로 설정하지 않은 경우 기본 리스너 소켓 이름은 /path/to/custom /socket override가 됩니다. .

그렇지 않고 rsyslog가 systemd에서 실행 중이고 /run/systemd/journal/syslog가 존재하는 경우(그리고 사용자가 SysSock.Use="off"를 명시적으로 설정하지 않은 경우) 기본 리스너 소켓 이름은 /run/systemd/ 저널 재정의 /가 됩니다. syslog.

시스템은 3단계에 도달하여 기본 경로를 "/run/systemd/journal/syslog"로 변경했지만 여전히 "/var/log"를 유지합니다. 이는 imuxsock 모듈이 systemd-journald-dev-log.socket에 의해 생성된 심볼릭 링크가 있어야 하는 /dev/log에 소켓을 생성하려고 (때때로 성공적으로) 시도한다는 것을 의미합니다. 실제 소켓을 생성할 수 없는 경우에도 심볼릭 링크는 삭제됩니다.

이 문서의 결과는이 문제rsyslog github에 보고하세요. 토론을 건너뛰고 변경 사항으로 바로 이동하려면 다음을 참조하세요.홍보 #1그리고홍보 #2각기.

내 해결책은 /etc/rsyslog.conf의 systemd 경로를 사용하도록 imuxsock 모듈을 구성하는 것이었습니다.

module(load="imuxsock"
    SysSock.Name="/run/systemd/journal/syslog")

이는 내 문제를 해결하는 것으로 보이며 심볼릭 링크를 수동으로 생성한 후 다시 사라질 수 있는 이유를 설명하므로 좋은 솔루션처럼 들립니다.

시스템을 보고 "/run/systemd/journal/syslog"가 존재하지 않는 경우 "syslog.socket"을 보고 성공적으로 시작되었는지 확인하십시오. 이것이 소켓 생성을 담당하는 것입니다.

systemctl status syslog.socket

rsyslog.service 버전이 서비스를 활성화하려고 할 때 syslog.socket에 필요한 별칭으로 syslog.service를 정의하지 않았을 수 있습니다. 여러 로깅 서비스에서 syslog.service의 별칭을 시도할 수도 있으며, 이 경우 마지막으로 활성화된 서비스가 우선합니다.

Answer