RHEL7'de bir çökme ve yeniden başlatma arasında nasıl bir ayrım yapabilirsiniz?


10

Bir RHEL7 sunucusunun systemctl (veya yeniden başlatma / kapatma takma adları) yoluyla yeniden başlatılıp başlatılmadığını veya sunucunun çöküp çökmediğini belirlemenin bir yolu var mı? Ön- last -x runlevelsistemd ile bunu belirlemek oldukça kolaydı , ancak RHEL7 ile o kadar net değil.

Yanıtlar:


4

Bunu yapmanın birden fazla yolu var, ama aklıma gelen en iyi 4 tanesini ele alacağım. (DÜZENLEME: Bunun redhat.com'daki genel bir makalesi olarak temizlenmiş bir sürümünü yayınladım. Bkz: RHEL 7'de bir çökme ve zarif bir yeniden başlatma arasında nasıl ayrım yapılır .)

(1) Denetim günlükleri

denetleme inanılmaz. Günlüğe kaydeddiği tüm farklı olayları işaretleyerek görebilirsiniz ausearch -m. Eldeki soruna göre, sistem kapatma ve sistem önyüklemesini günlüğe kaydeder, böylece komutu kullanabilirsiniz ausearch -i -m system_boot,system_shutdown | tail -4. Bu bir SYSTEM_SHUTDOWN ve ardından bir SYSTEM_BOOT bildirirse , her şey yolunda demektir ; ancak, arka arkaya 2 SYSTEM_BOOT satırı bildiriyorsa , aşağıdaki örnekte olduğu gibi sistem açıkça kapatılmamıştır:

[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) son -x

Yukarıdaki ile aynı, ancak basit last -n2 -x shutdown rebootkomut ile. Sistemin çöktüğü örnek:

[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)    

Veya sistemin zarif bir şekilde yeniden başlatılması:

[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) kendi servis biriminizi oluşturun

Bu IMHO'nun en iyi yaklaşımıdır, çünkü istediğiniz her şeye uyarlayabilirsiniz. Bunu yapmanın bir milyon yolu var. İşte yeni oluşturduğum. Bu sonraki hizmet yalnızca kapatma sırasında çalışır.

[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.

Daha sonra sistem önyükleme yaptığında, bu sonraki hizmet yalnızca yukarıdaki kapatma hizmeti tarafından oluşturulan dosya varsa başlar.

[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.

Böylece herhangi bir zamanda bir önceki önyükleme yaparak zarif bir kapatma sonra yapılıp yapılmadığını kontrol edebilirsiniz systemctl is-active check_graceful, örneğin:

[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.

Veya nankör bir kapanıştan sonra:

[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) dergi

systemd-journaldKalıcı bir günlük tutmak için yapılandırırsanız journalctl -b -1 -n, önceki önyüklemenin son birkaç (varsayılan olarak 10) satırına (bundan önceki önyükleme -b -2vb.) Bakmak için kullanabileceğinizi belirtmek gerekir . Sistemin zarif bir şekilde yeniden başlatıldığı örnek:

[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

Böyle iyi bir çıktı alırsanız, sistem açıkça incelikle kapatıldı. Bununla birlikte, kötü şeyler olduğunda (sistem çöktüğünde) benim deneyimimde süper güvenilir değil. Bazen indeksleme garipleşir.


8

Komik, dün gece bir CentOS 7 sistemini yeniden başlattım ve bu yüzden bakmak için güzel bir günlüğüm var.

Bir kilitlenme durumunda, kilitlenme süresi ile sistemin yeniden başlatılması arasında hiçbir şey kaydedilmez.

Yeniden başlatma durumunda, sistemin sistemi kapatmak için yaptığı her şeyin (neredeyse) bir kaydını aldığınızda oldukça açıktır.

Kapatmak veya tek kullanıcı moduna geçmek dışında hiçbir durumda göremeyeceğiniz böyle bir günlük girişi:

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

Gerçekte nelerin günlüğe kaydedildiğini görmek için kendi sisteminizi yeniden başlatabilirsiniz.


1
CentOS 7'nin bunu günlüğe kaydettiğine ve RHEL 7'nin kaydetmediğine inanıyor musunuz? CentOS (ve Fedora) günlüklerinde gördüklerimize dayanan ilk yaklaşımımız buydu. RHEL7 üzerinde test ettiğimizde zar yok.
kwb

1
@kwb Bir RHEL 7.2 sistemine baktıktan sonra, evet, inanıyorum. Aslında, günlüğe kaydedilmesi gereken birçok şeyin günlüğe kaydedilmediği anlaşılıyor. Tek söyleyebileceğim şey: WTF?
Michael Hampton

Neden bahsettiğinizden emin değilim. RHD 7.0-7.2'de systemd Stopping Multi-User Systemve Stopped target Multi-User Systemmesajları üretir .
16:51 de testere

@ rsaw Mesajların üretildiğinin farkındayız. Sorun, dergide görünmemeleri.
Michael Hampton

@MichaelHampton günlük varsayılan olarak kalıcı değildir. Eğer sürece Yalnızca geçerli çizme günlükleri görebilirsiniz mkdir /var/log/journalveya açıkça ayarlanmış Storage=persistentiçinde /etc/systemd/journald.conf. Ayrı bir cevap gönderdim.
16:45 de testere

5

Cevabı özellikle sevmiyorum, ancak RH'den aldığımız bir cevap. Başka birine yardım etmesi durumunda buraya gönderiyorum.

Olası bir yolu için yazılması etmektir rsyslogdiçinde /var/log/messages. Zarif bir kapanma olurdu exiting on signal 15. Bir çarpışma olmazdı.

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

Art arda iki startçizgi bir çökmeye işaret edebilir. Ve startardından gelen exitbir yeniden başlatmayı gösterebilir.

Ne yazık ki rsyslogd düşerse veya yeniden başlatma / çökme dışında yeniden başlatılırsa kötü sonuçlar verebilir.


Kötü oyun Red Hat. exiting on signal 15Yeniden başlatmanın yanı sıra bununla sonuçlanacak başka davranışlar da vardır . Normal service rsyslog restartmesaj exiting on signal 15mesajı ile de sonuçlanır .
Stefan Lasiewski

Bu geçerli bir cevap, ancak Red Hat teknik desteğinde çalışan biri olarak, benim gitmediğim şey bu değildi. Cevabımı gör.
16:48 de testere

1

Bu "zarif kapatmalar" için sürekli işin görünüyor ( shutdown, reboot, systemctl) ve "çöker" (güç kapalı, sıfırlama gibi echo c > /proc/sysrq-trigger):

last -x | grep 'reboot\|shutdown'

Bir rebootçizgiyi izleyen shutdownçizgi "zarif kapatma" yı gösterir. İki rebootçizgi bir "çökme" olduğunu gösterir.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.