답변:
이 작업을 수행하는 방법은 여러 가지가 있지만, 내가 생각할 수있는 가장 좋은 4 가지를 다룰 것입니다. (편집 : 나는이 버전의 정리 된 버전을 redhat.com에 공개 기사로 게시했습니다. RHEL 7에서 충돌과 정상적인 재부팅을 구별하는 방법을 참조하십시오 .)
감사는 훌륭합니다. 를 확인하여 기록하는 모든 다른 이벤트를 볼 수 있습니다 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'
위와 동일하지만 간단한 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)
이 방법은 원하는 방식으로 조정할 수 있으므로 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.
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
이와 같이 좋은 출력을 얻으면 시스템이 정상적으로 종료 된 것입니다. 즉, 나쁜 일이 발생했을 때 (시스템 충돌) 내 경험으로는 신뢰할 수 없습니다. 때때로 색인 생성이 이상해집니다.
유감스럽게도, 지난 밤에 CentOS 7 시스템을 재부팅하려고했기 때문에 이것에 대한 좋은 로그가 있습니다.
충돌의 경우 충돌 시간과 시스템 재시작 사이에 아무것도 기록되지 않습니다.
재부팅의 경우 시스템을 종료하기 위해 systemd가 수행하는 모든 작업에 대한 로그가 표시되므로 매우 분명합니다.
종료 또는 단일 사용자 모드로 전환하는 것 이외의 상황에서는 보이지 않는 로그 항목 중 하나는 다음과 같습니다.
Jul 13 01:27:55 yaungol systemd: Stopped target Multi-User System.
자신의 시스템을 재부팅하여 실제로 기록되는 내용을 볼 수 있습니다.
Stopping Multi-User System
및 Stopped target Multi-User System
메시지를 생성 합니다.
mkdir /var/log/journal
또는 명시 적으로 설정 Storage=persistent
에서 /etc/systemd/journald.conf
. 별도의 답변을 게시했습니다.
나는 그 대답을 특히 좋아하지 않지만 RH에서 얻은 대답입니다. 다른 사람을 돕기 위해 여기에 게시하고 있습니다.
가능한 방법 중 하나는에서 grep하는 것 rsyslogd
입니다 /var/log/messages
. 정상적으로 종료되면 exiting on signal 15
. 충돌하지 않습니다.
tac /var/log/messages | grep 'rsyslogd.*start\|rsyslogd.*exit'
연속 된 두 start
줄은 충돌을 나타냅니다. 그리고 start
뒤에 a exit
가 있으면 재부팅을 나타냅니다.
불행하게도 rsyslogd가 다운되거나 재부팅 / 충돌 밖에서 재시작되면 나쁜 결과를 초래할 수도 있습니다.
exiting on signal 15
재부팅 이외의 다른 동작이 있습니다 . service rsyslog restart
메시지 exiting on signal 15
메시지 도 정상 입니다.