내 KVM 서버 중 하나(2x Xeon E5-2680 v2, 1x AMD Vega 10 GPU, Ubuntu 20.04.1 LTS)가 어젯밤에 응답하지 않았습니다. 서버에서 실행 중인 5개의 가상 머신 중 하나만 액세스할 수 있습니다. 서버 자체가 SSH 연결을 거부하고 HDMI를 통해 화면을 얻을 수도 없습니다. 초기화 외에는 다른 해결책이 보이지 않습니다.
이 작업을 수행한 후에는 정확히 무슨 일이 일어나고 있는지 더 잘 이해하고 싶습니다. 시스템에서 다음 저널을 사용할 수 있습니다.
# journalctl --list-boots
-8 57c5ae37af1649379e82b349abb14f9d Sun 2020-05-24 20:25:57 CEST—Sun 2020-05-24 20:44:30 CEST
-7 c617acfdd3854669bd114d1d033cd5a7 Sun 2020-05-24 20:45:01 CEST—Mon 2020-05-25 19:21:48 CEST
-6 745df76c9d784907862118c7804a19ab Mon 2020-05-25 19:22:26 CEST—Mon 2020-05-25 19:42:17 CEST
-5 9781df6fa3494c4588d0cf4a99678e84 Mon 2020-05-25 19:42:59 CEST—Thu 2020-06-04 04:53:20 CEST
-4 db93d994719a4ee1ad8eb74932220898 Thu 2020-06-04 18:45:10 CEST—Thu 2020-06-04 19:16:38 CEST
-3 c6007ce834bd4933805138523549677e Thu 2020-06-04 19:17:20 CEST—Thu 2020-08-20 18:35:54 CEST
-2 c24b967697ce41a2ac6c1707936dc450 Thu 2020-08-20 18:36:23 CEST—Mon 2020-08-31 17:21:52 CEST
-1 b1efda1e7a3b42d4ae9a20f0c3b06fcf Mon 2020-09-07 09:49:24 CEST—Mon 2020-09-07 09:59:49 CEST
0 f5de0a1534a7478e87847031156976d0 Mon 2020-09-07 10:00:19 CEST—Mon 2020-09-07 10:08:33 CEST
목록에서 볼 수 있듯이 지난 7일간의 데이터가 누락되었으며 실제로 시스템 오류를 일으킨 로그에 접근할 수 없습니다.
실행하면 journalctl --verify다음 출력이 표시됩니다.
1f23cc0: Invalid object
File corruption detected at /var/log/journal/f9decb319623482392299509c566049a/[email protected]~:1f23cc0 (of 33554432 bytes, 97%).
FAIL: /var/log/journal/f9decb319623482392299509c566049a/[email protected]~ (Bad message)
PASS: /var/log/journal/f9decb319623482392299509c566049a/system@24f780e4155245c0a176021b285d8b61-0000000000000001-0005a744de2ec87d.journal
PASS: /var/log/journal/f9decb319623482392299509c566049a/user-1000@6da18e6709a04eb8809cb4af946ec557-00000000000008e3-0005a66900b2a7be.journal
PASS: /var/log/journal/f9decb319623482392299509c566049a/system@24f780e4155245c0a176021b285d8b61-0000000000010c89-0005a8cfc4df2d27.journal
PASS: /var/log/journal/f9decb319623482392299509c566049a/user-1000@6da18e6709a04eb8809cb4af946ec557-0000000000010c88-0005a8cfc4dec165.journal
PASS: /var/log/journal/f9decb319623482392299509c566049a/system@24f780e4155245c0a176021b285d8b61-000000000001b654-0005ab341293df34.journal
PASS: /var/log/journal/f9decb319623482392299509c566049a/user-1000@6da18e6709a04eb8809cb4af946ec557-000000000001bf95-0005ab56000dcbe1.journal
PASS: /var/log/journal/f9decb319623482392299509c566049a/[email protected]~
PASS: /var/log/journal/f9decb319623482392299509c566049a/system@cf2a7210a86040e6aa7736d9b0a88e8b-0000000000000001-0005aeb4750dab5e.journal
PASS: /var/log/journal/f9decb319623482392299509c566049a/system.journal
PASS: /var/log/journal/f9decb319623482392299509c566049a/user-1000@6da18e6709a04eb8809cb4af946ec557-00000000000269b9-0005ad9c6a92da4a.journal
PASS: /var/log/journal/f9decb319623482392299509c566049a/user-1000.journal
몇몇 명백한 웹 검색 결과를 살펴보면 현재로서는 손상된 일기장을 복구할 수 있는 방법이 없고 그냥 사라지는 것 같습니다. 솔직히 말해서, systemd의 책임자가 손상된 Journalctl 항목을 고칠 필요가 없다고 생각한다고 썼을 때 나는 그것이 조금 이상하다는 것을 알았습니다. 그러나 아마도 그것은 단지 나일 것입니다.
나는 정말로 무엇을 해야할지 모르겠습니다. 내 경우 /var/log에도 파일에 전화를 걸었지만 syslog8월 31일에 중단되었고 오늘도 계속되었습니다. 에 대해서도 마찬가지입니다 kern. Xorg 및 dmesg와 같은 다른 로그 파일을 살펴보았습니다. 솔직히 무엇을 찾아야 할지조차 몰랐지만 아무것도 나를 흥분시키지 않는 것 같았습니다.
Xorg.log에는 단 하나의 오류만 표시되는데, 이는 내 문제의 원인이 아닐 것 같습니다.
[230912.637] (II) xfree86: Adding drm device (/dev/dri/card0)
[230912.637] (EE) /dev/dri/card0: failed to set DRM interface version 1.4: Permission denied
dmesg에는 오류나 실패 메시지가 없는 것 같습니다.
내 말은, 현재는 모든 것이 잘 작동하고 있지만 이 오류가 몇 주에 한 번씩 반복되는 것 같습니다. 이 문제를 더 잘 이해하기 위해 어떤 다른 조치를 취할 수 있습니까?
답변1
journalctl --list-boots모든 일지를 보여주지 는 않을 것 같아요문서, 오직이벤트 시작. ~에서수동:
--list-boots실행 번호(현재 실행 기준), 해당 ID, 실행과 관련된 첫 번째 및 마지막 메시지의 타임스탬프를 표시하는 표 형식 목록입니다.
그러니까 아닌 것 같애부츠2020-08-31 17:21:52 및 2020-09-07 09:49:24 사이에 발생했습니다. 이것이 틀렸다는 것을 안다면 일지에 실제로 공백이 있는 것입니다.
그러나 특정 시간 이후 또는 이전에 발생한 모든 (기타) 메시지를 확인할 수 있습니다. 이 특별한 사건은 내가 이 글을 쓰는 동안 오래 전에 일어났지만, 다음과 같이 진행될 것입니다:
journalctl --since '2020-09-06' --until '2020-09-08
이는 전날 자정부터 다음날 자정까지 48시간 동안 적용됩니다. -k커널 메시지에 대해서만 추가로 필터링 할 수 있습니다 .
로그가 있으면 인쇄됩니다. 만약 정말로 누락되었다면, 우리는 일지에 뭔가 문제가 있다는 것을 알고 있습니다.
Journalctl은 저널에서 손상된 메시지를 건너뛰어야 하지만 여전히 가능한 내용을 인쇄해야 합니다. 나는 이 문제에 대한 버그 보고서가 매우 경솔한 답변을 얻었다는 데 동의하지만의도예, 나쁜 소식은 건너뛰어야 합니다. 이 출력에서 보면 로그 파일의 대부분은 괜찮은 것으로 보이지만 --verify끝 부분에서 손상이 발생합니다(시스템이 충돌할 때 작성되는 불완전한 메시지로 인해 발생할 수 있음).