Linux 커널 개발자는 기본적으로 /dev/kmsg 메시지 속도 제한을 결정했습니다. 이는 시스템이 쓰는 메시지의 양, 특히 debug커널 명령줄에 전달되는 메시지의 양을 좋아하지 않기 때문입니다 .
디버그 메시지가 활성화되지 않은 경우에도 systemd는 이 제한을 초과합니다.
[ 5.879211] systemd: 18 output lines suppressed due to ratelimiting
dmesg이것은 현재 내 커널 로그()에 있는 유일한 메시지입니다. 따라서 이는 t=5.879211 부근에서 끝나는 18개의 연속 행만 손실된다는 의미라고 생각할 수 있습니다. 어떤 의미에서 이것은 상당히 제한적인 손실이 될 것입니다. 매우 초기의 시작 단위(저널 전)가 실패하는 것을 발견하지 않는 한 걱정할 필요가 없을 것입니다.
그렇다면 그렇습니까? 어떤 경우에는 이 분석이 나를 오해할 수 있습니까?
답변1
사실 이 생각은 매우 잘못된 것입니다. 첫째, 이 메시지는 반드시 18개의 연속된 systemd 메시지로 구성된 단일 블록이 손실되었음을 나타내지는 않습니다. 둘째, 프로세스가 아직 쓰기 가능한 상태라면 /dev/kmsg가 속도 제한을 받는 시기를 알 수 없습니다. 프로세스가 종료될 때만 /dev/kmsg에 대한 메시지를 받게 됩니다. 이 메시지는 해당 작성자의 모든 표시되지 않은 줄 수를 표시합니다.
각 개별 작성자(파일 설명자)는 /dev/kmsg자체 속도 제한 구조를 갖습니다. 초기화의 일부로...
ratelimit_set_flags(&user->rs, RATELIMIT_MSG_ON_RELEASE);
속도 제한은 로그인 게시 전용으로 설정됩니다. 즉, 파일 설명자가 닫힐 때입니다. 장기 실행 프로세스의 경우 이는 큰 도움이 되지 않을 수 있습니다. 그리고 init 시스템(즉, systemd)은 확실히 장기 실행 프로세스로 간주됩니다.
이 로그 메시지가 표시되는 이유는 initrd의 systemd가 exec()시스템 루트 파일 시스템의 systemd보다 먼저 /dev/kmsg를 닫았기 때문입니다.
따라서 initrd 중에 손실된 메시지가 반드시 블록으로 손실되는 것은 아닙니다. 누락된 메시지가 여러 개 있을 수 있으므로 로그 분석이 생각만큼 간단하지 않습니다.
또한 exec()루트 파일 시스템에서 systemd를 실행하면 /dev/kmsg에 대한 로깅이 완전히 중지되고 journald. systemd exec()의 systemd-shutdown, /dev/kmsg가 자동으로 종료되면 다음을 볼 수 있습니다.
[ OK ] Reached target Final Step.
Starting Reboot...
[ 76.318839] systemd-shutdow: 32 output lines suppressed due to ratelimiting
...
이는 커널의 일부 속도 제한 메시지와 대조됩니다 kauditd_printk_skb: 32 callbacks suppressed. 이 경우 RATELIMIT_MSG_ON_RELEASE는 사용되지 않습니다.