Làm thế nào bạn có thể phân biệt giữa một sự cố và khởi động lại trên RHEL7?


9

Có cách nào để xác định xem máy chủ RHEL7 có được khởi động lại thông qua systemctl (hoặc bí danh khởi động lại / tắt máy) hay không, liệu máy chủ có bị sập không? Pre-systemd điều này khá dễ xác định last -x runlevel, nhưng với RHEL7 thì không rõ lắm.

Câu trả lời:


3

Có nhiều hơn một cách để làm điều này, nhưng tôi sẽ đề cập đến 4 cách tốt nhất tôi có thể nghĩ ra. (EDIT: Tôi đã xuất bản phiên bản đã được dọn sạch này dưới dạng một bài viết công khai trên redhat.com. Xem: Cách phân biệt giữa sự cố và khởi động lại duyên dáng trong RHEL 7. )

(1) Nhật ký kiểm toán

Audd là tuyệt vời. Bạn có thể thấy tất cả các sự kiện khác nhau mà nó ghi lại bằng cách kiểm tra ausearch -m. Áp dụng cho vấn đề hiện tại, nó ghi nhật ký tắt hệ thống và khởi động hệ thống, do đó bạn có thể sử dụng lệnh ausearch -i -m system_boot,system_shutdown | tail -4. Nếu điều này báo cáo một HỆ THỐNG_SHUTDOWN theo sau là HỆ THỐNG_BOOT , thì tất cả đều ổn; tuy nhiên, nếu nó báo cáo 2 dòng HỆ THỐNG_BOOT liên tiếp, thì rõ ràng hệ thống đã không tắt một cách duyên dáng, như trong ví dụ sau:

[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) cuối -x

Tương tự như trên, nhưng với last -n2 -x shutdown rebootlệnh đơn giản . Ví dụ nơi hệ thống bị sập:

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

Hoặc nơi hệ thống đã khởi động lại duyên dáng:

[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) tạo đơn vị dịch vụ của riêng bạn

Đây là IMHO cách tiếp cận tốt nhất bởi vì bạn có thể điều chỉnh nó theo bất cứ điều gì bạn muốn. Có một triệu cách để làm điều này. Đây là một cái tôi vừa tạo nên. Dịch vụ tiếp theo này chỉ chạy khi tắt máy.

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

Sau đó, khi hệ thống khởi động, dịch vụ tiếp theo này sẽ chỉ bắt đầu nếu tệp được tạo bởi dịch vụ tắt máy ở trên tồn tại.

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

Vì vậy, tại bất kỳ thời điểm nào tôi cũng có thể kiểm tra xem lần khởi động trước đã được thực hiện sau khi tắt máy duyên dáng bằng cách thực hiện systemctl is-active check_graceful, ví dụ:

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

Hoặc đây là sau khi tắt máy vô duyên:

[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) tạp chí

Điều đáng nói là nếu bạn định cấu hình systemd-journaldđể giữ một tạp chí liên tục, thì bạn có thể sử dụng journalctl -b -1 -nđể xem một vài dòng (10 theo mặc định) cuối cùng của lần khởi động trước ( -b -2là lần khởi động trước đó, v.v.). Ví dụ trong đó hệ thống khởi động lại một cách duyên dáng:

[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

Nếu bạn có được đầu ra tốt như vậy, thì rõ ràng hệ thống đã được tắt một cách duyên dáng. Điều đó nói rằng, nó không đáng tin cậy theo kinh nghiệm của tôi khi điều tồi tệ xảy ra (sự cố hệ thống). Đôi khi việc lập chỉ mục trở nên kỳ lạ.


7

Thật buồn cười, tôi vừa tình cờ khởi động lại một hệ thống CentOS 7 tối qua, và vì vậy tôi có một nhật ký tuyệt vời chỉ để xem xét.

Trong trường hợp xảy ra sự cố, rõ ràng không có gì được ghi lại giữa thời điểm xảy ra sự cố và hệ thống khởi động lại.

Trong trường hợp khởi động lại, nó khá rõ ràng, khi bạn nhận được một bản ghi (gần như) mọi thứ systemd đang làm để tắt hệ thống.

Một mục nhật ký như vậy bạn không thể thấy trong bất kỳ trường hợp nào ngoài việc tắt hoặc chuyển sang chế độ một người dùng là:

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

Bạn có thể khởi động lại hệ thống của riêng bạn để xem những gì thực sự được ghi lại.


1
Bạn có tin rằng CentOS 7 ghi lại điều này và RHEL 7 không? Đó là cách tiếp cận ban đầu của chúng tôi dựa trên những gì chúng tôi thấy trong nhật ký của CentOS (và Fedora). Khi chúng tôi thử nghiệm trên RHEL7, không có xúc xắc.
kwb

1
@kwb Sau khi xem qua hệ thống RHEL 7.2, vâng, tôi tin điều đó. Trên thực tế, có vẻ như rất nhiều thứ nên được ghi lại không được ghi lại. Tất cả những gì tôi có thể nói là: WTF?
Michael Hampton

Không chắc chắn những gì các bạn đang nói về. systemd trong RHEL 7.0-7.2 tạo Stopping Multi-User SystemStopped target Multi-User Systemthông báo.
rsaw

@rsaw Chúng tôi nhận thức rõ rằng các tin nhắn được tạo ra. Vấn đề là chúng không xuất hiện trên tạp chí.
Michael Hampton

@MichaelHampton tạp chí không tồn tại theo mặc định. Bạn chỉ có thể xem các bản ghi từ khởi động hiện tại của bạn, trừ khi bạn mkdir /var/log/journalhoặc một cách rõ ràng thiết lập Storage=persistenttrong /etc/systemd/journald.conf. Tôi đăng một câu trả lời riêng.
rsaw

5

Tôi không đặc biệt thích câu trả lời, nhưng đó là câu trả lời chúng tôi nhận được từ RH. Tôi đang đăng nó ở đây trong trường hợp nó giúp người khác.

Một cách có thể là grep cho rsyslogdtrong /var/log/messages. Một tắt máy duyên dáng sẽ có exiting on signal 15. Một vụ tai nạn sẽ không.

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

Hai startdòng liên tiếp có thể chỉ ra một vụ tai nạn. Và starttheo sau bởi một exitcó thể chỉ ra một khởi động lại.

Thật không may, nó cũng có thể cho kết quả xấu nếu rsyslogd bị hỏng hoặc được khởi động lại bên ngoài khởi động lại / sự cố.


Chơi xấu Mũ Đỏ. Có những hành vi khác sẽ dẫn đến điều đó exiting on signal 15bên cạnh việc khởi động lại. Một bình thường service rsyslog restartcũng dẫn đến tin exiting on signal 15nhắn.
Stefan Lasiewski

Đây là một câu trả lời hợp lệ, nhưng là một người làm việc trong bộ phận hỗ trợ công nghệ của Red Hat, đó không phải là điều tôi sẽ làm. Xem câu trả lời của tôi.
rsaw

1

Điều này dường như làm việc liên tục cho "tắt máy duyên dáng" ( shutdown, reboot, systemctl) cũng như "tai nạn" (tắt nguồn, khởi động lại, echo c > /proc/sysrq-trigger):

last -x | grep 'reboot\|shutdown'

Một rebootdòng theo sau là một shutdowndòng cho biết "tắt máy duyên dáng". Hai rebootdòng chỉ ra một "sự cố".

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.