RHEL7에서 충돌과 재부팅을 어떻게 구분할 수 있습니까?


10

RHEL7 서버가 systemctl을 통해 재부팅되었는지 (또는 재부팅 / 종료 별명) 또는 서버가 충돌했는지 여부를 판별하는 방법이 있습니까? 사전 last -x runlevel시스템화 는이 방법으로 결정하기 가 쉽지만 RHEL7에서는 그다지 명확하지 않습니다.

답변:


4

이 작업을 수행하는 방법은 여러 가지가 있지만, 내가 생각할 수있는 가장 좋은 4 가지를 다룰 것입니다. (편집 : 나는이 버전의 정리 된 버전을 redhat.com에 공개 기사로 게시했습니다. RHEL 7에서 충돌과 정상적인 재부팅을 구별하는 방법을 참조하십시오 .)

(1) 감사 로그

감사는 훌륭합니다. 를 확인하여 기록하는 모든 다른 이벤트를 볼 수 있습니다 ausearch -m. 현재 문제에 대한 제안으로 시스템 종료 및 시스템 부팅을 기록하므로 명령을 사용할 수 있습니다 ausearch -i -m system_boot,system_shutdown | tail -4. 이것이 SYSTEM_SHUTDOWN 다음에 SYSTEM_BOOT를 보고하면 모두 정상 입니다. 그러나 2 개의 SYSTEM_BOOT 행을 연속으로 보고 하면 다음 예제와 같이 시스템이 정상적으로 종료되지 않은 것입니다.

[root@a72 ~]# ausearch -i -m system_boot,system_shutdown | tail -4
----
type=SYSTEM_BOOT msg=audit(09/20/2016 01:10:32.392:7) : pid=657 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(09/20/2016 01:11:41.134:7) : pid=656 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' 

(2) 마지막 -x

위와 동일하지만 간단한 last -n2 -x shutdown reboot명령을 사용하십시오. 시스템이 충돌 한 예 :

[root@a72 ~]# last -n2 -x shutdown reboot
reboot   system boot  3.10.0-327.el7.x Tue Sep 20 01:11 - 01:20  (00:08)    
reboot   system boot  3.10.0-327.el7.x Tue Sep 20 01:10 - 01:20  (00:09)    

또는 시스템이 정상적으로 재부팅 된 경우 :

[root@a72 ~]# last -n2 -x shutdown reboot
reboot   system boot  3.10.0-327.el7.x Tue Sep 20 01:21 - 01:21  (00:00)    
shutdown system down  3.10.0-327.el7.x Tue Sep 20 01:21 - 01:21  (00:00)    

(3) 자신의 서비스 단위를 만듭니다

이 방법은 원하는 방식으로 조정할 수 있으므로 IMHO 최선의 방법입니다. 이를 수행하는 방법은 백만 가지가 있습니다. 여기 내가 방금 만든 것이 있습니다. 이 다음 서비스는 종료시에만 실행됩니다.

[root@a72 ~]# cat /etc/systemd/system/set_gracefulshutdown.service
[Unit]
Description=Set flag for graceful shutdown
DefaultDependencies=no
RefuseManualStart=true
Before=shutdown.target

[Service]
Type=oneshot
ExecStart=/bin/touch /root/graceful_shutdown

[Install]
WantedBy=shutdown.target
[root@a72 ~]# systemctl enable set_gracefulshutdown.service 
Created symlink from /etc/systemd/system/shutdown.target.wants/set_gracefulshutdown.service to /etc/systemd/system/set_gracefulshutdown.service.

그런 다음 시스템이 부팅 될 때이 다음 서비스는 위의 종료 서비스에 의해 생성 된 파일이 존재하는 경우에만 시작됩니다.

[root@a72 ~]# cat /etc/systemd/system/check_graceful.service 
[Unit]
Description=Check if system booted after a graceful shutdown
ConditionPathExists=/root/graceful_shutdown
RefuseManualStart=true
RefuseManualStop=true

[Service]
Type=oneshot
RemainAfterExit=true
ExecStart=/bin/rm /root/graceful_shutdown

[Install]
WantedBy=multi-user.target
[root@a72 ~]# systemctl enable check_graceful
Created symlink from /etc/systemd/system/multi-user.target.wants/check_graceful.service to /etc/systemd/system/check_graceful.service.

따라서 언제든지 다음을 수행하여 정상 종료 후 이전 부팅이 완료되었는지 확인할 수 있습니다 systemctl is-active check_graceful.

[root@a72 ~]# systemctl is-active check_graceful && echo YAY || echo OH NOES
active
YAY
[root@a72 ~]# systemctl status check_graceful
● check_graceful.service - Check if system booted after a graceful shutdown
   Loaded: loaded (/etc/systemd/system/check_graceful.service; enabled; vendor preset: disabled)
   Active: active (exited) since Tue 2016-09-20 01:10:32 EDT; 20s ago
  Process: 669 ExecStart=/bin/rm /root/graceful_shutdown (code=exited, status=0/SUCCESS)
 Main PID: 669 (code=exited, status=0/SUCCESS)
   CGroup: /system.slice/check_graceful.service

Sep 20 01:10:32 a72.example.com systemd[1]: Starting Check if system booted after a graceful shutdown...
Sep 20 01:10:32 a72.example.com systemd[1]: Started Check if system booted after a graceful shutdown.

또는 다음은 비정상적인 종료 후입니다.

[root@a72 ~]# systemctl is-active check_graceful && echo YAY || echo OH NOES
inactive
OH NOES
[root@a72 ~]# systemctl status check_graceful
● check_graceful.service - Check if system booted after a graceful shutdown
   Loaded: loaded (/etc/systemd/system/check_graceful.service; enabled; vendor preset: disabled)
   Active: inactive (dead)
Condition: start condition failed at Tue 2016-09-20 01:11:41 EDT; 16s ago
           ConditionPathExists=/root/graceful_shutdown was not met

Sep 20 01:11:41 a72.example.com systemd[1]: Started Check if system booted after a graceful shutdown.

(4) 저널

systemd-journald영구 저널을 유지 하도록 구성 journalctl -b -1 -n하면 이전 부팅의 마지막 몇 줄 (기본적으로 10 개)을 볼 수 있습니다 (이전의 부팅 -b -2등). 시스템이 정상적으로 재부팅 된 예 :

[root@a72 ~]# mkdir /var/log/journal
[root@a72 ~]# systemctl -s SIGUSR1 kill systemd-journald
[root@a72 ~]# reboot
...
[root@a72 ~]# journalctl -b -1 -n
-- Logs begin at Tue 2016-09-20 01:01:15 EDT, end at Tue 2016-09-20 01:21:33 EDT. --
Sep 20 01:21:19 a72.example.com systemd[1]: Stopped Create Static Device Nodes in /dev.
Sep 20 01:21:19 a72.example.com systemd[1]: Stopping Create Static Device Nodes in /dev...
Sep 20 01:21:19 a72.example.com systemd[1]: Reached target Shutdown.
Sep 20 01:21:19 a72.example.com systemd[1]: Starting Shutdown.
Sep 20 01:21:19 a72.example.com systemd[1]: Reached target Final Step.
Sep 20 01:21:19 a72.example.com systemd[1]: Starting Final Step.
Sep 20 01:21:19 a72.example.com systemd[1]: Starting Reboot...
Sep 20 01:21:19 a72.example.com systemd[1]: Shutting down.
Sep 20 01:21:19 a72.example.com systemd-shutdown[1]: Sending SIGTERM to remaining processes...
Sep 20 01:21:19 a72.example.com systemd-journal[483]: Journal stopped

이와 같이 좋은 출력을 얻으면 시스템이 정상적으로 종료 된 것입니다. 즉, 나쁜 일이 발생했을 때 (시스템 충돌) 내 경험으로는 신뢰할 수 없습니다. 때때로 색인 생성이 이상해집니다.


8

유감스럽게도, 지난 밤에 CentOS 7 시스템을 재부팅하려고했기 때문에 이것에 대한 좋은 로그가 있습니다.

충돌의 경우 충돌 시간과 시스템 재시작 사이에 아무것도 기록되지 않습니다.

재부팅의 경우 시스템을 종료하기 위해 systemd가 수행하는 모든 작업에 대한 로그가 표시되므로 매우 분명합니다.

종료 또는 단일 사용자 모드로 전환하는 것 이외의 상황에서는 보이지 않는 로그 항목 중 하나는 다음과 같습니다.

Jul 13 01:27:55 yaungol systemd: Stopped target Multi-User System.

자신의 시스템을 재부팅하여 실제로 기록되는 내용을 볼 수 있습니다.


1
CentOS 7이이를 기록하고 RHEL 7은이를 기록하지 않는다고 생각하십니까? 이는 CentOS (및 Fedora) 로그에서 본 내용을 기반으로 한 초기 접근 방식이었습니다. RHEL7에서 테스트했을 때 주사위는 없습니다.
kwb

1
@kwb RHEL 7.2 시스템을 살펴본 후 그렇습니다. 실제로, 기록해야 할 많은 것들이 기록되지 않는 것 같습니다. 내가 말할 수있는 것은 : WTF?
Michael Hampton

너희들이 무슨 말을하는지 모르겠다. RHEL 7.0-7.2에서 systemd는 Stopping Multi-User SystemStopped target Multi-User System메시지를 생성 합니다.
rsaw

@rsaw 우리는 메시지가 생성된다는 것을 잘 알고 있습니다. 문제는 그들이 저널에 나타나지 않는다는 것입니다.
Michael Hampton

@MichaelHampton 저널은 기본적으로 영구적이지 않습니다. 당신이하지 않으면 당신은 현재 부트의 로그를 볼 수 있습니다 mkdir /var/log/journal또는 명시 적으로 설정 Storage=persistent에서 /etc/systemd/journald.conf. 별도의 답변을 게시했습니다.
rsaw

5

나는 그 대답을 특히 좋아하지 않지만 RH에서 얻은 대답입니다. 다른 사람을 돕기 위해 여기에 게시하고 있습니다.

가능한 방법 중 하나는에서 grep하는 것 rsyslogd입니다 /var/log/messages. 정상적으로 종료되면 exiting on signal 15. 충돌하지 않습니다.

tac /var/log/messages | grep 'rsyslogd.*start\|rsyslogd.*exit'

연속 된 두 start줄은 충돌을 나타냅니다. 그리고 start뒤에 a exit가 있으면 재부팅을 나타냅니다.

불행하게도 rsyslogd가 다운되거나 재부팅 / 충돌 밖에서 재시작되면 나쁜 결과를 초래할 수도 있습니다.


Red Hat이 잘못되었습니다. exiting on signal 15재부팅 이외의 다른 동작이 있습니다 . service rsyslog restart메시지 exiting on signal 15메시지 도 정상 입니다.
Stefan Lasiewski

이것은 정답이지만, Red Hat 기술 지원 부서에서 일하는 사람은 제가 함께했던 것이 아닙니다. 내 대답을 참조하십시오.
rsaw

1

이것은 "우아한 종료"를 지속적으로 작동하는 것 같다 ( shutdown, reboot, systemctl)뿐만 아니라 "충돌"(전원 차단, 리셋 등 echo c > /proc/sysrq-trigger) :

last -x | grep 'reboot\|shutdown'

reboota로 다음 라인 shutdown라인은 "정상 종료"를 나타냅니다. 두 reboot줄은 "충돌"을 나타냅니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.