Arch Linux에서 systemd로 "업그레이드"한 이후로 예상치 못한 작동 중지가 발생하면 로그가 계속 손실됩니다. 나는 싸운다동일한 로그 손실 문제한 달 전에 이 문제가 다시 발생했습니다. 그 밖에도 독립된확인.
상태:
- Java 및 네트워크 관련 유틸리티로 작업을 수행하는 동안 KDE(시계)가 정지되는 것을 발견했습니다. CPU 팬에서 소음이 발생하고 열이 계속 상승합니다. 하지만 마우스 포인터는 여전히 움직일 수 있습니다.
- 다른 컴퓨터에서 SSH를 시도했습니다("호스트에 대한 경로 없음"으로 인해 실패함).
- 나는 몇 분 동안 기다렸습니다. 어쩌면 NMI 감시자가 문제가 있는 작업을 종료할 수도 있었습니다. 주사위가 없습니다.
- Ctrl++는 + 이후에도 작동 Alt하지 F1않습니다.SysRqR
- 위의 단계가 작동하지 않았기 때문에 SysRq 시퀀스 REI를 발행하기로 결정했습니다. 그 후 E화면은 검게 변하지만 콘솔도 없습니다. + 이후에도 SysRq아님K
- 따라서 세션이 손실된 것으로 보이며 할 수 있는 유일한 작업은 디버깅 정보를 수집하는 것뿐입니다. 보고 있다위키피디아SysRq, + d(디스플레이 잠김) 등을 누르기로 결정했습니다 .
- SysRq+를 누른 후 S잠시 기다렸다가 SysRq+로 다시 시작했습니다 B.
- 재부팅하고 콘솔에 로그인한 후에는 충돌 흔적이 표시되지 않습니다. 가장 최근에 기록된 항목은 Wireshark를 사용한 항목이지만 여전히 45분의 간격이 있습니다.
(그런데 저는 Linux v3.8-rc5-218-ga56e160을 실행하고 있습니다)
그렇다면 잠금으로 인해 예기치 않은 재부팅이 발생하는 경우 로그가 보존되도록 하려면 어떻게 해야 합니까?
답변1
그래서 #systemd IRC 채널에 문의한 결과 저널드(systemd의 저널 데몬)가 정기적으로 디스크에 로그를 전혀 플러시하지 않는다는 것을 알게 되었습니다. 이는 귀하의 로그가 항상 위험에 노출되어 있음을 의미합니다.
SIGUSR2로그 에 게시하면 journald로그가 디스크에 기록되지만 이를 여러 번 수행하면 많은 파일이 생성됩니다. (이 옵션은 실제로 "로그 회전"으로 설명됩니다.)
마지막으로 나는 또 다른 제안을 하기로 결정했습니다: 전용 syslog 데몬을 사용하여 커널 로그를 수집하는 것입니다. rsyslog가 제안되었으므로(그리고 이미 이를 사용한 경험이 있음) 해당 옵션을 더 자세히 살펴보았습니다. 자세한 내용은 에 썼어요아치스 위키rsyslog 사용 정보.
아이디어는 rsyslog를 실행하고 커널 시설에서만 데이터를 수집하는 것입니다. rsyslog 읽기 /proc/kmsg(단일 판독기만 허용) 및 Journald 읽기 (여러 판독기 허용) 로 인해 /dev/kmsg데몬이 로그를 잃는 것은 불가능합니다(저에게 매우 중요합니다!). 커널 메시지를 파일에 기록하도록 rsyslog를 구성하고, 디스크 공간 소모를 방지하기 위해 파일을 순환해야 합니다.
이 솔루션은 완벽하지 않습니다.
- NetworkManager의 로그와 같은 다른 로그는 손실됩니다. 이 문제는 다음과 같이 해결될 수 있습니다.syslog에서 Journald로 더 많은 로그 전달(이것은 중복을 의미합니다!)
- 로그가 중복되었습니다. 커널 메시지는 두 개의 파일에 기록됩니다. 이는 문제가 되지 않습니다. 일반적으로 로그 수가 적으므로 로그 복사본이 없는 것보다 더 많은 로그 복사본이 있는 것이 좋습니다.
grep단일 로그 파일 과 같은 빠른 도구나 느리지만 고급 도구를 사용할 수도 있습니다journalctl.
하나 있다할 일 목록로그를 더 자주 플러시하는 데 사용되지만 여전히 충분히 신뢰할 수 없습니다.
로그: 수시로 마커 메시지를 보낸 다음 즉시 fdatasync()와 동기화하여 매시간 동기화를 보장합니다.
이제 systemd/journald에는 디스크에 로그를 쓸 수 있는 옵션이 있기를 바라지만 그 동안 목표를 달성하기 위해 도구를 결합할 수 있습니다.
답변2
두 가지 업데이트가 있습니다:
- 이제 systemd/journald에는 디스크에 로그를 쓸 수 있는 옵션이 있기를 바라지만 그 동안 목표를 달성하기 위해 도구를 결합할 수 있습니다.
옵션이 있습니다--sync:
기록되지 않은 모든 로그 데이터를 백업 파일 시스템에 쓰고 모든 로그를 동기화하도록 로그 데몬에게 요청합니다. 이 호출은 동기화 작업이 완료될 때까지 반환되지 않습니다. 이 명령은 호출 전에 작성된 모든 로그 메시지가 반환 시 디스크에 안전하게 저장되도록 보장합니다.
--sync에서 사용 가능v228:
Journalctl은 로그 데몬이 지금까지 기록되지 않은 모든 로그 메시지를 디스크에 쓰고 반환하기 전에 파일을 동기화하도록 요구하는 새로운 "--sync" 스위치를 얻었습니다.
- Journald(systemd의 저널 데몬)는 정기적으로 로그를 디스크에 플러시하지 않는 것으로 나타났습니다. 이는 귀하의 로그가 항상 위험에 노출되어 있음을 의미합니다.
man journald.conf(5)설명하다:
동기화 간격(초) =
로그 파일을 디스크에 동기화하기 전 시간 초과입니다. 동기화 후 로그 파일은 OFFLINE 상태가 됩니다. 우선순위가 CRIT, ALERT, EMERG인 로그 메시지를 로깅한 후 무조건 즉시 동기화가 완료된다는 점에 유의하세요. 따라서 이 설정은 ERR, WARNING, NOTICE, INFO, DEBUG 수준 메시지에만 적용됩니다. 기본 제한 시간은 5분입니다.
SyncIntervalSec=에서 사용 가능v199:
Journald는 이제 각 쓰기 후 5분 이내에 명시적으로 로그 파일을 디스크에 플러시합니다. 그러면 파일은 다음에 쓸 때까지 오프라인으로 표시됩니다. 이를 통해 충돌 발생 시 안정성이 향상됩니다. 동기화 지연은 Journald.conf의 SyncIntervalSec=를 통해 구성할 수 있습니다.
또한보십시오:
Journald: 낮은 우선순위로 SIGTERM/SIGINT 전송
종료 시 대기 중인 모든 로그 데이터가 처리되어 종료 시 불필요한 메시지가 손실되지 않도록 합시다.