계획되지 않은 방식으로 또는 알 수 없는 명백한 이유 때문에 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'
캡처된 이벤트는 항상 구체적이지 않을 수 있습니다. 시스템 전원 끄기/충돌로 이어질 수 있는 경고 또는 오류의 징후를 나타내는 이벤트를 항상 추적하십시오.
감사 로그 확인
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 $
위의 출력에서 저널에 기록된 메시지를 관찰하고 이상이 있는 경우 이를 추적할 수 있습니다.
결론
단일 명령이나 단일 로그 파일을 사용하여 Linux 재부팅의 원인을 정확히 찾아내는 것이 항상 가능한 것은 아닙니다. 따라서 시스템 관련 이벤트를 캡처하고 근본 원인을 찾는 데 필요한 시간을 단축할 수 있는 명령과 로그를 아는 것이 항상 편리합니다.
위의 예는 문제 해결을 시작할 수 있는 출발점을 제공합니다. 이러한 도구와 로그를 함께 사용하면 어떤 일이 발생했고 시스템이 어떻게 재부팅되었는지 확실히 알 수 있습니다.
다음으로 Linux용 경량 모니터링 소프트웨어를 찾으십시오.