Linux 재부팅 이유를 찾는 방법은 무엇입니까?

계획되지 않은 방식으로 또는 알 수 없는 명백한 이유 때문에 Linux 시스템이 재부팅되는 경우가 종종 있습니다. 근본 원인을 찾아 해결하면 이러한 문제의 재발을 방지하고 계획되지 않은 다운타임을 방지하는 데 도움이 될 수 있습니다.

재부팅을 유발한 원인을 찾을 수 있는 몇 가지 방법이 있습니다. 이 기사에서는 이러한 방법과 Linux 시스템에서 사용 가능한 유틸리티 및 로그를 활용하여 이러한 시나리오의 문제를 해결할 수 있는 방법에 대해 설명합니다.

재부팅 시간 검사

who 및 last 명령으로 시스템 재부팅이 발생한 시점을 확인할 수 있습니다.

$ who -b
system boot 2021-02-13 20:51

$ last -x | head | tac
abhishek pts/0 192.168.1.16 Sat Feb 13 19:53 - 19:55 (00:02)
reboot system boot 3.10.0-1160.11.1 Sat Feb 13 19:55 - 20:54 (00:58)
runlevel (to lvl 3) 3.10.0-1160.11.1 Sat Feb 13 19:55 - 20:04 (00:08)
abhishek pts/0 192.168.1.16 Sat Feb 13 19:56 - 20:04 (00:07)
reboot system boot 3.10.0-1160.11.1 Sat Feb 13 20:04 - 20:54 (00:49)
runlevel (to lvl 3) 3.10.0-1160.11.1 Sat Feb 13 20:04 - 20:51 (00:46)
abhishek pts/0 192.168.1.16 Sat Feb 13 20:04 - 20:50 (00:46)
reboot system boot 3.10.0-1160.11.1 Sat Feb 13 20:51 - 20:54 (00:03)
runlevel (to lvl 3) 3.10.0-1160.11.1 Sat Feb 13 20:51 - 20:54 (00:02)
abhishek pts/0 192.168.1.16 Sat Feb 13 20:51 still logged in
$

시스템 메시지 확인

진단하려는 재부팅을 시스템 메시지와 추가로 연관시킬 수 있습니다.

CentOS/RHEL 시스템의 경우 /var/log/messages에서 로그를 찾을 수 있고 Ubuntu/Debian 시스템의 경우 /var/log/syslog에서 로그를 찾을 수 있습니다. tail 명령이나 좋아하는 텍스트 편집기를 사용하여 특정 데이터를 필터링하거나 찾을 수 있습니다.

아래 로그에서 유추할 수 있듯이 이러한 항목은 관리자 또는 루트 사용자가 시작한 종료/재부팅을 제안합니다. 이러한 메시지는 OS 유형과 재부팅/종료가 트리거되는 방식에 따라 다를 수 있지만 매번 원인을 정확히 지적할 만큼 명시적이지 않을 수 있지만 시스템 로그를 보면 항상 유용한 정보를 찾을 수 있습니다.

Feb 13 19:56:20 centos7vm chronyd[637]: Source 72.30.35.89 replaced with 142.147.92.5
Feb 13 20:00:40 centos7vm chronyd[637]: Selected source 162.159.200.123
Feb 13 20:01:01 centos7vm systemd: Created slice User Slice of root.
Feb 13 20:01:01 centos7vm systemd: Started Session 2 of user root.
Feb 13 20:04:09 centos7vm systemd-logind: System is powering down.
Feb 13 20:04:09 centos7vm systemd: Closed LVM2 poll daemon socket.
Feb 13 20:04:09 centos7vm systemd: Stopped target Multi-User System.

시스템 로그를 필터링하는 데 사용할 수 있는 명령 중 하나는 다음과 같습니다.

sudo grep -iv ': starting|kernel: .*: Power Button|watching system buttons|Stopped Cleaning Up|Started Crash recovery kernel' 
  /var/log/messages /var/log/syslog /var/log/apcupsd* 
  | grep -iw 'recover[a-z]*|power[a-z]*|shut[a-z ]*down|rsyslogd|ups'

캡처된 이벤트는 항상 구체적이지 않을 수 있습니다. 시스템 전원 끄기/충돌로 이어질 수 있는 경고 또는 오류의 징후를 나타내는 이벤트를 항상 추적하십시오.

Electronplayer를 사용하여 Linux 데스크톱에서 Netflix를 시청하는 방법

감사 로그 확인

auditd가 있는 시스템의 경우 ausearch 도구를 사용하여 다양한 이벤트를 확인할 수 있는 좋은 장소입니다. 아래 명령을 사용하여 감사 로그에서 마지막 두 항목을 확인하십시오.

$ sudo ausearch -i -m system_boot,system_shutdown | tail -4

이것은 가장 최근에 두 번 종료 또는 재부팅을 보고합니다. 이것이 SYSTEM_SHUTDOWN 다음에 SYSTEM_BOOT가 보고되면 모든 것이 정상입니다. 그러나 한 행에 두 개의 SYSTEM_BOOT 행이 보고되거나 단일 SYSTEM_BOOT 행만 보고되면 시스템이 정상적으로 종료되지 않았을 가능성이 큽니다. 정상적인 출력은 다음과 같아야 합니다.

$ sudo ausearch -i -m system_boot,system_shutdown | tail -4
----
type=SYSTEM_SHUTDOWN msg=audit(Saturday 13 February 2021 A.852:8) : pid=621 uid=root auid=unset ses=unset subj=system_u:system_r:init_t:s0 msg=' comm=systemd-update-utmp exe=/usr/lib/systemd/systemd-update-utmp hostname=? addr=? terminal=? res=success'
----
type=SYSTEM_BOOT msg=audit(Saturday 13 February 2021 A.368:8) : pid=622 uid=root auid=unset ses=unset subj=system_u:system_r:init_t:s0 msg=' comm=systemd-update-utmp exe=/usr/lib/systemd/systemd-update-utmp hostname=? addr=? terminal=? res=success'
$

아래 출력은 두 개의 연속적인 SYSTEM_BOOT 메시지를 나열하며, 이는 시스템 로그와 연관되어야 하지만 비정상 종료를 나타낼 수 있습니다.

$ sudo ausearch -i -m system_boot,system_shutdown | tail -4
----
type=SYSTEM_BOOT msg=audit(Saturday 13 February 2021 A.852:8) : pid=621 uid=root auid=unset ses=unset subj=system_u:system_r:init_t:s0 msg=' comm=systemd-update-utmp exe=/usr/lib/systemd/systemd-update-utmp hostname=? addr=? terminal=? res=success'
----
type=SYSTEM_BOOT msg=audit(Saturday 13 February 2021 A.368:8) : pid=622 uid=root auid=unset ses=unset subj=system_u:system_r:init_t:s0 msg=' comm=systemd-update-utmp exe=/usr/lib/systemd/systemd-update-utmp hostname=? addr=? terminal=? res=success'
$

시스템 저널 분석

영구 저널을 디스크에 유지하려면 영구 systemd-journal이 있어야 합니다. 그렇지 않으면 재부팅 시 로그가 지속되지 않습니다. 이를 위해 /etc/systemd/journald.conf에서 변경하거나 아래 명령을 사용하여 직접 디렉토리를 생성할 수 있습니다.

$ sudo mkdir /var/log/journal
$ sudo systemd-tmpfiles --create --prefix /var/log/journal 2>/dev/null
$ sudo systemctl -s SIGUSR1 kill systemd-journald

완료되면 선택적으로 시스템을 재부팅하여 필수는 아니지만 저널에 둘 이상의 재부팅 항목을 캡처할 수 있습니다.

아래 명령을 사용하여 저널에서 기록된 부팅을 나열합니다.

$ journalctl --list-boots

내 서버의 출력은 다음과 같습니다.

$ journalctl --list-boots
-15 8a7c8034da804ebb9cb063a7553ed0bf Wed 2020-11-18 23:09:05 IST—Wed 2020-11-18 23:17:10 IST
-14 7bbb9542778a4057a91b9d22fcf91735 Wed 2020-11-18 23:17:22 IST—Wed 2020-11-18 23:20:08 IST
-13 f2ee8a61bf4c4f67a12e012855d8b1c3 Wed 2020-11-18 23:20:17 IST—Wed 2020-11-18 23:23:01 IST
-12 1277d19a959f4c33ba944a68c5874d2a Fri 2020-12-11 10:32:44 IST—Fri 2020-12-11 10:43:39 IST
-11 eb4ff97f112445888a5946d1155de1b8 Fri 2020-12-11 10:43:55 IST—Fri 2020-12-11 10:48:18 IST
-10 bf46eff3f9a344d2b28a03ffbf7fff32 Fri 2020-12-11 19:04:30 IST—Fri 2020-12-11 19:31:01 IST
 -9 2acf08368667423c89086579f98efd82 Tue 2020-12-15 17:36:52 IST—Tue 2020-12-15 19:13:10 IST
 -8 b826f223a67d454b94d4413678870f08 Sat 2020-12-19 00:31:54 IST—Sat 2020-12-19 00:44:52 IST
 -7 011e1b29339041b0ae48bbb93fce792f Wed 2020-12-23 23:01:15 IST—Wed 2020-12-23 23:02:44 IST
 -6 f41f5880572e4394938c6dcb4a8b683c Mon 2020-12-28 16:54:11 IST—Mon 2020-12-28 22:54:22 IST
 -5 a2e638dc292a4db2b0a50dd442129c28 Tue 2020-12-29 17:02:16 IST—Tue 2020-12-29 19:39:38 IST
 -4 f6c738df872a48d48daee1962727cca5 Wed 2020-12-30 19:09:30 IST—Wed 2020-12-30 19:20:23 IST
 -3 c876e60ea371460b94e247b40270b18f Thu 2020-12-31 14:36:07 IST—Thu 2020-12-31 15:45:36 IST
 -2 a23c70804ec243f7868c18737f4b7e55 Sat 2021-02-13 20:09:30 IST—Sat 2021-02-13 20:10:44 IST
 -1 94b604a6bf75462dac8c4a4576fdc863 Sat 2021-02-13 20:10:59 IST—Sat 2021-02-13 20:23:18 IST
  0 3ff7e29fa0a34878b7574b7d4d3ccfb5 Sat 2021-02-13 20:24:57 IST—Sat 2021-02-13 21:13:15 IST
$

보시다시피 여러 부츠가 나열되어 있습니다. 특정 재부팅을 추가로 분석하려면 다음을 사용하십시오.

$ journalctl -b {num} -n

여기서 {num}은 첫 번째 열의 journalctl –list-boots 명령에 제공된 인덱스입니다.

$ journalctl -b -1 -n
-- Logs begin at Wed 2020-11-18 23:09:05 IST, end at Sat 2021-02-13 21:13:39 IST. --
Feb 13 20:23:18 ubuntumate20vm systemd[1]: lvm2-monitor.service: Succeeded.
Feb 13 20:23:18 ubuntumate20vm systemd[1]: Stopped Monitoring of LVM2 mirrors, snapshots etc. using dmeventd or progress polling.
Feb 13 20:23:18 ubuntumate20vm systemd[1]: Reached target Shutdown.
Feb 13 20:23:18 ubuntumate20vm systemd[1]: Reached target Final Step.
Feb 13 20:23:18 ubuntumate20vm systemd[1]: systemd-poweroff.service: Succeeded.
Feb 13 20:23:18 ubuntumate20vm systemd[1]: Finished Power-Off.
Feb 13 20:23:18 ubuntumate20vm systemd[1]: Reached target Power-Off.
Feb 13 20:23:18 ubuntumate20vm systemd[1]: Shutting down.
Feb 13 20:23:18 ubuntumate20vm systemd-shutdown[1]: Syncing filesystems and block devices.
Feb 13 20:23:18 ubuntumate20vm systemd-journald[304]: Journal stopped
$

위의 출력에서 저널에 기록된 메시지를 관찰하고 이상이 있는 경우 이를 추적할 수 있습니다.

직장을 위한 4가지 최고의 Linux 배포판

결론

단일 명령이나 단일 로그 파일을 사용하여 Linux 재부팅의 원인을 정확히 찾아내는 것이 항상 가능한 것은 아닙니다. 따라서 시스템 관련 이벤트를 캡처하고 근본 원인을 찾는 데 필요한 시간을 단축할 수 있는 명령과 로그를 아는 것이 항상 편리합니다.

위의 예는 문제 해결을 시작할 수 있는 출발점을 제공합니다. 이러한 도구와 로그를 함께 사용하면 어떤 일이 발생했고 시스템이 어떻게 재부팅되었는지 확실히 알 수 있습니다.

다음으로 Linux용 경량 모니터링 소프트웨어를 찾으십시오.