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 명령어 또는 원하는 텍스트 편집기를 사용하여 특정 데이터를 필터링하거나 검색할 수 있습니다.

아래 제시된 로그 예시에서 볼 수 있듯이, 이러한 항목들은 관리자 또는 루트 사용자에 의한 종료/재부팅을 암시합니다. 이러한 메시지는 운영체제 종류 및 재부팅/종료 트리거 방식에 따라 다를 수 있으며, 매번 정확한 원인을 지적할 만큼 명확하지 않을 수 있습니다. 하지만, 시스템 로그를 살펴보면 항상 유용한 정보를 얻을 수 있습니다.

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'
  

기록된 이벤트는 항상 구체적이지 않을 수 있습니다. 시스템 전원 끄기/충돌로 이어질 수 있는 경고 또는 오류의 징후를 나타내는 이벤트를 지속적으로 확인해야 합니다.

감사 로그를 통한 이벤트 추적

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
$
  

위의 출력에서 저널에 기록된 메시지를 자세히 살펴보고, 비정상적인 부분이 발견된다면 이를 추적할 수 있습니다.

결론

단일 명령어 또는 단일 로그 파일만으로 리눅스 재부팅 원인을 정확하게 찾아내는 것은 항상 가능한 일은 아닙니다. 그러므로, 시스템 관련 이벤트를 파악하고 근본 원인을 찾는데 필요한 시간을 절약하기 위해 관련 명령어와 로그에 대한 이해도를 높이는 것이 중요합니다.

위에서 제시된 예시들은 문제 해결을 위한 시작점을 제공합니다. 이러한 도구와 로그를 종합적으로 활용함으로써, 어떤 일이 발생했는지, 시스템이 어떤 과정을 거쳐 재부팅되었는지 보다 명확하게 파악할 수 있을 것입니다.

다음 단계로, 리눅스 시스템을 위한 경량 모니터링 소프트웨어를 알아보세요.