วิธีการค้นหาจากบันทึกสิ่งที่ทำให้เกิดการปิดระบบ?


104

เช่นฉันเห็นสิ่งนี้ใน/var/log/messages:

Mar 01 23:12:34 hostname shutdown: shutting down for system halt

มีวิธีหาสาเหตุที่ทำให้เกิดการปิดระบบหรือไม่ เช่นมีการเรียกใช้จากคอนโซลหรือมีคนกดปุ่มเปิด / ปิด ฯลฯ ?


2
ดังนั้นในครั้งนี้มีโชคด้วย/var/log/acpid: เปิดออกปุ่มเพาเวอร์ถูกตี ความคิดอื่นใดที่จะดูว่า acpid ไม่ได้ให้เงื่อนงำ?
alex

คำตอบ:


45

เฉพาะโปรแกรมที่มีสิทธิ์ใช้งานรูทเท่านั้นที่สามารถปิดระบบได้ ดังนั้นเมื่อระบบปิดในวิธีปกติผู้ใช้ที่มีสิทธิ์รูทหรือสคริปต์ acpi ในทั้งสองกรณีคุณสามารถค้นหาโดยตรวจสอบบันทึก การปิดระบบ acpi อาจเกิดจากการกดปุ่มเปิดปิดเครื่อง, ความร้อนสูงเกินไปหรือแบตเตอรี่ต่ำ (แล็ปท็อป) ฉันลืมเหตุผลที่สามคือซอฟต์แวร์ UPS เมื่อไฟดับซึ่งจะส่งการแจ้งเตือนต่อไป

เมื่อเร็ว ๆ นี้ฉันมีระบบที่เริ่มซ้ำ ๆ เพื่อปิดเครื่องอย่างไม่สุภาพหันกลับมาว่ามันร้อนเกินไปและ mobo ได้รับการกำหนดค่าให้ปิดเครื่องเร็วเท่านั้น ระบบไม่มีโอกาสบันทึกล็อก แต่โชคดีที่การตรวจสอบอุณหภูมิของระบบแสดงว่ามันเริ่มเพิ่มขึ้นก่อนที่จะปิดเครื่อง

ดังนั้นหากเป็นการปิดระบบปกติมันจะถูกบันทึกหากมีการบุกรุก ... ขอให้โชคดีและหากเป็นการปิดระบบเย็นโอกาสที่ดีที่สุดของคุณคือการควบคุมและตรวจสอบสภาพแวดล้อม


118

ลองคำสั่งต่อไปนี้:

แสดงรายการของรายการรีบูตล่าสุด: last reboot | less

แสดงรายการของรายการปิดระบบล่าสุด: last -x | less

หรือมากกว่าแม่นยำ: last -x | grep shutdown | less

คุณจะไม่รู้ว่าใครเป็นคนทำ หากคุณต้องการรู้ว่าใครทำคุณจะต้องเพิ่มรหัสเล็กน้อยซึ่งหมายความว่าคุณจะรู้ในครั้งต่อไป

ฉันได้พบทรัพยากรนี้ออนไลน์ อาจเป็นประโยชน์กับคุณ:

จะค้นหาว่าใครหรือสิ่งใดหยุดระบบของฉัน


25
นี่ไม่ได้บอกฉันว่าอะไรเป็นสาเหตุของการปิดเครื่องเฉพาะเมื่อเสร็จแล้ว ที่ฉันรู้แล้วดูคำถามของฉัน
alex

1
แม่นยำยิ่งขึ้นlast -x shutdown
ราหุลปาติล

5
ลงคะแนนเนื่องจากไม่ได้ตอบคำถาม
toogley

1
ลิงค์นี้มีไว้สำหรับ "ฉันจะรู้ได้อย่างไรว่าใครเป็นคนหยุดระบบของฉัน(Old Sco Unix)? "
Wolfgang

16

การตรวจสอบมีสองสิ่ง:

ตรวจสอบเอาต์พุตของคำสั่ง -x ที่ผ่านมา

รันคำสั่งนี้ * และเปรียบเทียบผลลัพธ์กับตัวอย่างด้านล่าง:

last -x | head | tac

ตัวอย่างการปิดเครื่องปกติ

การปิดและการเปิดเครื่องตามปกติมีลักษณะดังนี้ (โปรดทราบว่าคุณมีเหตุการณ์การปิดระบบจากนั้นจึงเป็นเหตุการณ์การบูตระบบ):

runlevel (to lvl 0)   2.6.32- Sat Mar 17 08:48 - 08:51  (00:02) 
shutdown system down  ... <-- first the system shuts down   
reboot   system boot  ... <-- afterwards the system boots
runlevel (to lvl 3)       

ในบางกรณีคุณอาจเห็นสิ่งนี้ (โปรดทราบว่าไม่มีบรรทัดเกี่ยวกับการปิดระบบ แต่ระบบอยู่ที่ runlevel 0 ซึ่งเป็น "สถานะหยุด"):

runlevel (to lvl 0)   ... <-- first the system shuts down (init level 0)
reboot   system boot  ... <-- afterwards the system boots
runlevel (to lvl 2)   2.6.24-... Fri Aug 10 15:58 - 15:32 (2+23:34)   

ตัวอย่างการปิดที่ไม่คาดคิด

การปิดที่ไม่คาดคิดจากการสูญเสียพลังงานมีลักษณะเช่นนี้ (โปรดทราบว่าคุณมีเหตุการณ์การบูตระบบโดยไม่มีเหตุการณ์การปิดระบบก่อนหน้า):

runlevel (to lvl 3)   ... <-- the system was running since this momemnt
reboot   system boot  ... <-- then we've a boot WITHOUT a prior shutdown
runlevel (to lvl 3)   3.10.0-693.21.1. Sun Jun 17 15:40 - 09:51  (18:11)    

ตรวจสอบบันทึกใน / var / log

คำสั่ง bash เพื่อกรองข้อความบันทึกที่น่าสนใจที่สุดคือ:

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'

เมื่อระบบดับลงโดยไม่คาดคิดหรือความล้มเหลวของฮาร์ดแวร์เกิดขึ้นระบบไฟล์จะไม่ถูกถอดออกอย่างถูกต้องดังนั้นในการบู๊ตครั้งถัดไปคุณอาจได้รับบันทึกดังนี้:

EXT4-fs ... INFO: recovery required ... 
Starting XFS recovery filesystem ...
systemd-fsck: ... recovering journal
systemd-journald: File /var/log/journal/.../system.journal corrupted or uncleanly shut down, renaming and replacing.

เมื่อระบบปิดเนื่องจากผู้ใช้กดปุ่มเปิดปิดคุณจะได้รับบันทึกดังนี้:

systemd-logind: Power key pressed.
systemd-logind: Powering Off...
systemd-logind: System is powering down.

เมื่อระบบปิดอย่างเป็นระเบียบคุณจะได้รับบันทึกดังนี้:

rsyslogd: ... exiting on signal 15

เมื่อระบบปิดตัวลงเนื่องจากความร้อนสูงเกินไปคุณจะได้รับบันทึกดังนี้:

critical temperature reached...,shutting down

หากคุณมี UPS และใช้ daemon เพื่อตรวจสอบพลังงานและการปิดเครื่องคุณควรตรวจสอบบันทึกอย่างชัดเจน (บันทึก NUT ใน / var / log / ข้อความ แต่บันทึก apcupsd บน / var / log / apcupsd *)


หมายเหตุ

*: นี่คือคำอธิบายของlastจากหน้าแรก:

last [...] prints information about connect times of users. 
Records are printed from most recent to least recent.  
[...]
The special users reboot and shutdown log in when the system reboots
or (surprise) shuts down. 

เราใช้headเพื่อเก็บ 10 เหตุการณ์ล่าสุดและเราใช้tacเพื่อสลับการสั่งซื้อเพื่อให้เราไม่สับสนโดยข้อเท็จจริงที่ว่าการพิมพ์ครั้งล่าสุดจากเหตุการณ์ล่าสุดถึงเหตุการณ์ล่าสุดน้อยที่สุด


คำตอบที่ดี. ในเดเบียนของฉัน 9 ฉันไม่เห็นบรรทัด "runlevel (to lvl 0)" สำหรับการปิดปกติ
Jruv

@jruv คุณเห็นสิ่งที่ชอบ? ผมคิดว่ามันควรจะได้รับ "ระบบปิดลง"
ndemou

นี่เป็นตัวอย่างที่ดี แต่อาจได้รับประโยชน์จากการทำซ้ำโดยไม่ใช้tacคำสั่ง
mbigras

ตรวจสอบ / var / log นั่นเป็นคำสั่งที่ดีและเป็นข้อมูลที่ดี ขอบคุณ!
Howard Lee

11

บางล็อกไฟล์ที่เป็นไปได้ในการสำรวจ: (พบระบบ Ubuntu แต่ฉันหวังว่าไฟล์เหล่านั้นจะปรากฏในระบบ Linux / Unix ส่วนใหญ่)

/var/log/debug
/var/log/syslog (will be pretty full and may be harder to browse)
/var/log/user.log
/var/log/kern.log
/var/log/boot

อีกครั้งไฟล์บันทึกเหล่านี้มีอยู่ในระบบ Ubuntu ดังนั้นชื่อไฟล์อาจแตกต่างกัน tailคำสั่งเป็นเพื่อนของคุณ


8

ลดความซับซ้อนโดยใช้การlastแสดงรายการปิดระบบและเรียกใช้การเปลี่ยนแปลงระดับและการกรองshutdownและreboot:

last -x shutdown reboot

1
ndefontenayพูดถึงแล้วว่า ขอบคุณสำหรับการบริจาค แต่โปรดอ่านคำตอบที่มีอยู่ก่อน
Gilles

ฉันคิดว่าคำตอบของฉันง่ายขึ้นวันหนึ่ง แต่ขอขอบคุณ
jhvaras

1
@ gilles ฉันต้องบอกว่านี่แตกต่างอย่างละเอียดในแบบcat foo | grep barvs grep bar fooดูเหมือนว่าสุดท้ายจะสามารถกรองตัวเองได้
xenoterracide

8

ไม่พอใจอย่างเต็มที่

ฉันมีความต้องการคล้าย ๆ กับ Debian 7.8 และสังเกตว่าโดยทั่วไปไม่มีข้อความที่ชัดเจนและชัดเจนในบันทึกซึ่งเป็นเรื่องที่น่าแปลกใจเล็กน้อย

Grep through /var/logจะบอกเวลาที่เครื่องถูกปิดแสดง daemons ที่ถูกปิด ฯลฯ แต่ไม่ใช่เหตุผลเริ่มต้น

shutdown[25861]: shutting down for system halt

โซลูชันอื่น ๆ ที่กล่าวถึง ( last -x) ไม่ได้ช่วยอะไรมาก

กำลังมองหาวิธีการทำงาน

การอ่าน/etc/acpi/powerbtn-acpi-support.shซึ่งรวมถึง:

ถ้า [-x /etc/acpi/powerbtn.sh]; แล้วก็
    # ความเข้ากันได้กับสคริปต์ปรับแต่งเก่าจากแพ็คเกจ acpid
    /etc/acpi/powerbtn.sh
elif [-x /etc/acpi/powerbtn.sh.dpkg-bak]; แล้วก็
        # ความเข้ากันได้กับสคริปต์ปรับแต่งเก่าจากแพ็คเกจ acpid
    # ซึ่งยังรอบเพราะมันถูกเปลี่ยนโดยผู้ดูแลระบบ
        /etc/acpi/powerbtn.sh.dpkg-bak
อื่น
    # การจัดการปกติ
    / sbin / shutdown -h -P ทันที "กดปุ่มเพาเวอร์"
Fi

ขอให้สังเกตว่าข้อความที่ชัดเจนจะได้รับเป็นพารามิเตอร์ของshutdownคำสั่ง ฉันคาดว่าสตริงนั้นจะถูกบันทึกโดยอัตโนมัติโดยโปรแกรมปิดเครื่อง

การปรับเพื่อบันทึกที่ดีขึ้น

อย่างไรก็ตามเพื่อให้ได้ข้อความที่ชัดเจนฉันใส่ข้อความด้านล่าง (เป็น root) ในไฟล์ที่สร้างขึ้นใหม่/etc/acpi/powerbtn.shซึ่งสามารถเรียกใช้งานได้chmod a+x /etc/acpi/powerbtn.sh

#! / bin / ดวลจุดโทษ
คนตัดไม้ใน /etc/acpi/powerbtn.sh สันนิษฐานว่า "ปุ่มเพาเวอร์กด"
    / sbin / shutdown -h -P ทันที "กดปุ่มเพาเวอร์"

/etc/acpi/powerbtn-acpi-support.shทำมันด้วยวิธีนี้อาจจะทำให้เกิดการเปลี่ยนแปลงที่ยั่งยืนนานกว่าการปรับเปลี่ยน acpi-support-baseตัวเลือกหลังอาจจะสูญเสียผลกระทบต่อการปรับรุ่นต่อไปของแพคเกจ

ประกาศกว่า Ubuntu 14.04 แตกต่างกัน ( /etc/acpi/powerbtn.shมีอยู่แล้วกับเนื้อหาที่แตกต่างจากacpidแพ็คเกจ) นอกจากนี้ Debian 8 อาจทำแตกต่างออกไป รู้สึกอิสระที่จะเสนอสายพันธุ์

กำไร!

และตอนนี้เมื่อปุ่มเพาเวอร์ถูกกดสายเช่นนี้ปรากฏใน/var/log/messages, /var/log/syslogและ/var/log/user.log:

logger: in /etc/acpi/powerbtn.sh, presumably Power button pressed

ตอนนี้เป็นข้อความที่ชัดเจนในบันทึก


ขอบคุณ @Bielecki ที่แนะนำให้พิจารณาการติดตั้งacpi-support-baseและacpidแพ็คเกจ ฉันไม่ได้ทดสอบตัวเอง คุณช่วยให้รายละเอียดเกี่ยวกับการกระจายและรุ่นที่ให้ผลประโยชน์ได้หรือไม่
Stéphane Gourichon

4

ฉันมีความคิดที่ซุ่มซ่าม แต่บางทีมันก็ใช้ได้กับคุณ: ป้อนคำสั่งlastและตรวจสอบข้อมูลการเข้าสู่ระบบสำหรับผู้ใช้ทั้งหมด จากนั้นกรองผู้ใช้รายที่มีสิทธิ์ที่จำเป็นสำหรับสิ่งhaltนั้นที่ได้เข้าสู่ระบบในขณะนั้น จากนั้นตรวจสอบ.bash_historyไฟล์เพื่อดูว่าพวกเขาได้หยุดหรือไม่


1

ในกรณีของฉันฉันมีปัญหาเรื่องความร้อนสูงเกินไปและพบว่าการเข้าสู่ระบบ / var / log / syslog โดย 'grep shut *' ในโฟลเดอร์ / var / log

ข้อผิดพลาดที่บันทึกไว้คือ:

Feb 23 15:59:49 luca-LIFEBOOK-A530 kernel: [24746.497174] thermal thermal_zone0: critical temperature reached(99 C),shutting down

1

เพียงชิปในนั้นบน KVM VM ของฉัน (ที่ฉันสงสัยว่าโฮสต์รีบูตทำการปิดระบบของผู้เข้าพักได้อย่างสะอาดหมดจด) หรือไม่ฉันพบสิ่งที่ฉันต้องการใน/var/log/auth.log(นอกเหนือจากการlast -x shutdownแสดงเดียวกัน) มีบรรทัดเหล่านี้ปรากฏขึ้น:

Sep  3 23:56:31 Web systemd-logind[531]: Power key pressed.
Sep  3 23:56:31 Web systemd-logind[531]: Powering Off...
Sep  3 23:56:31 Web systemd-logind[531]: System is powering down.
Sep  3 23:55:45 Web systemd-logind[591]: New seat seat0.
Sep  3 23:55:45 Web systemd-logind[591]: Watching system buttons on /dev/input/event0 (Power Button)
Sep  3 23:55:54 Web sshd[805]: Server listening on 0.0.0.0 port 22.
Sep  3 23:55:54 Web sshd[805]: Server listening on :: port 22.

last -xแสดงบรรทัดเหล่านี้โปรดสังเกตว่าพวกเขากำลังพิมพ์ตามลำดับล่าสุดส่วนใหญ่ (เช่นอ่านบรรทัดสุดท้ายก่อนจากนั้นขึ้นไป) แต่เนื่องจากการรีเซ็ตนาฬิกา (23:56 ก่อนบู๊ต 23:55 หลังจากนั้น) ยังเห็นได้ชัดในบรรทัดก่อนหน้าคำสั่งดูเหมือนสับสนเล็กน้อย:

runlevel (to lvl 2)   3.13.0-129-gener Sun Sep  3 23:55 - 22:04  (22:08)    
reboot   system boot  3.13.0-129-gener Sun Sep  3 23:55 - 22:04  (22:08)    
shutdown system down  3.13.0-123-gener Sun Sep  3 23:56 - 23:55  (00:00)    
runlevel (to lvl 0)   3.13.0-123-gener Sun Sep  3 23:56 - 23:56  (00:00)

สำหรับส่วนของฉันการตรวจสอบว่าแขกได้รับการปิดอย่างสมบูรณ์เมื่อโฮสต์ถูกบูทฉันสามารถเข้าสู่ระบบ (ssh) หนึ่งแขกและอยู่ที่นั่นเมื่อฉันบูตโฮสต์รับสายเหล่านี้ใน terminal:

root@Web:~#
Broadcast message from root@Web
        (unknown) at 22:25 ...

The system is going down for power off NOW!
Connection to web closed by remote host.
Connection to web closed.

0

นามแฝงการปิดสคริปต์
สคริปต์ที่จะต้องให้พารามิเตอร์ทั้งหมด ฯลฯ เพื่อการปฏิบัติการปิดระบบเดิม
แต่สคริปต์จะต้องเข้าสู่ระบบเหล่านี้


2
สคริปต์การปิดระบบทำสิ่งนี้แล้ว ( last -x)
forcefsck

-1
cat /usr/adm/syslog

ในกรณีของฉันมันเป็นซอฟต์แวร์อัพปิดเซิร์ฟเวอร์

/etc/rc.d/7/upsd.boot

สิ่งนี้ไม่ได้ให้คำตอบสำหรับคำถาม เมื่อคุณมีเพียงพอชื่อเสียงคุณจะสามารถที่จะแสดงความคิดเห็นในโพสต์ใด ๆ ; แทนที่จะให้คำตอบที่ไม่จำเป็นต้องชี้แจงจากผู้ถาม - จากการรีวิว
Jeff Schaller

@JeffSchaller ฉันคิดว่ามันเป็นคำตอบเท่านั้นไม่ดีมาก
user259412
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.