ข้อความเมื่อปิดระบบ: สุนัขเฝ้าบ้านไม่ได้หยุด!


19

เมื่อปิดเครื่องฉันมักจะได้รับข้อความ

watchdog did not stop!

และแล็ปท็อปค้างหลังจากสายอื่น ๆ ไม่กี่โดยไม่ต้องปิดเครื่อง

ความคิดเกี่ยวกับวิธีการแก้ไขปัญหานี้? เมื่อเร็ว ๆ นี้มันเกิดขึ้นบ่อยครั้งมากเมื่อเปิดแล็ปท็อปมาระยะหนึ่ง

ฉันใช้ Debian 8 ใน Asus UX32LA

ฉันพบไฟล์ systemd นี้ (มันแสดงความขัดแย้งกับ shutdown.target) ถ้ามันอาจช่วยได้ ความประทับใจของฉันคือว่าปัญหาขึ้นอยู่กับปัญหาบางอย่างที่มาจากฉันพยายามที่จะแก้ไขแสงไฟ (ซึ่งจริง ๆ แล้วใช้ได้เฉพาะกับพารามิเตอร์ด้วง "acpi_osi =")

[Unit]
Description=Load/Save Screen Backlight Brightness of %i
Documentation=man:systemd-backlight@.service(8)
DefaultDependencies=no
RequiresMountsFor=/var/lib/systemd/backlight
Conflicts=shutdown.target  
After=systemd-readahead-collect.service systemd-readahead-replay.service     systemd-remount-fs.service
Before=sysinit.target shutdown.target

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/lib/systemd/systemd-backlight load %i
ExecStop=/lib/systemd/systemd-backlight save %i

1
คุณลองลบ "rhgb quiet" ออกจาก boot cmdline แล้วดูว่าเกิดอะไรขึ้น?
shubham

สิ่งที่ฉันอยากจะแนะนำ "rhgb เงียบ" ระงับข้อความเมื่อบูต / ปิดเครื่องซึ่งอาจมีประโยชน์มากที่นี่
ทิมเอส

ไม่มี "rhgb เงียบ" ใน / etc / default / grub (และปรับปรุง grub)
Reyx_0

ในเดเบียนตัวเลือกที่เทียบเท่าเพื่อลบคือ "เงียบสแปลช"
telcoM

คำตอบ:


16

watchdog did not stop!บรรทัดเป็นพฤติกรรมปกติ systemdตั้งค่าตัวจับเวลา" ฮาร์ดแวร์เฝ้าดู " เป็นความล้มเหลวเพื่อให้แน่ใจว่าหากกระบวนการปิดปกติหยุดการทำงาน / ล้มเหลวว่าคอมพิวเตอร์จะยังคงปิดเครื่องหลังจากระยะเวลาที่กำหนด ช่วงเวลานี้ถูกกำหนดไว้ในตัวแปรในแฟ้มShutdownWatchdogSec= /etc/systemd/system.confนี่คือคำอธิบายจากเอกสาร :

RuntimeWatchdogSec =, ShutdownWatchdogSec =

กำหนดค่าจ้องจับผิดฮาร์ดแวร์ที่รันไทม์และเมื่อรีบูต ใช้ค่าการหมดเวลาเป็นวินาที (หรือในหน่วยเวลาอื่นหากต่อท้ายด้วย "ms", "min", "h", "d", "w") หาก RuntimeWatchdogSec = ตั้งเป็นค่าที่ไม่เป็นศูนย์ฮาร์ดแวร์ watchdog (/ dev / watchdog) จะถูกตั้งโปรแกรมให้รีบูทระบบโดยอัตโนมัติหากไม่ได้รับการติดต่อภายในช่วงเวลาหมดเวลาที่ระบุ ผู้จัดการระบบจะตรวจสอบให้แน่ใจว่าได้ติดต่ออย่างน้อยหนึ่งครั้งในช่วงเวลาการหมดเวลาที่ระบุ คุณลักษณะนี้ต้องการอุปกรณ์จ้องจับผิดฮาร์ดแวร์ที่จะปรากฏในกรณีทั่วไปในระบบฝังตัวและเซิร์ฟเวอร์ ไม่ใช่ watchdogs ของฮาร์ดแวร์ทั้งหมดที่อนุญาตการกำหนดค่าการหมดเวลาการรีบูตซึ่งในกรณีนี้การเลือกไทม์เอาต์ที่ใกล้เคียงที่สุดจะถูกเลือก ShutdownWatchdogSec = อาจใช้เพื่อกำหนดค่าฮาร์ดแวร์ watchdog เมื่อระบบขอให้รีบูต มันทำหน้าที่เป็นตาข่ายนิรภัยเพื่อให้แน่ใจว่าการรีบูตเกิดขึ้นแม้ว่าการรีบูตเครื่องใหม่หมดเวลา โดยค่าเริ่มต้น RuntimeWatchdogSec = เริ่มต้นที่ 0 (ปิด) และ ShutdownWatchdogSec = ถึง 10 นาที การตั้งค่าเหล่านี้ไม่มีผลหากไม่สามารถใช้งาน Watchdog ของฮาร์ดแวร์ได้

อาจเป็นไปได้ว่าปัญหาที่แท้จริงของคุณเกี่ยวข้องกับการเปลี่ยนการตั้งค่า ACPI คำตอบในเธรดฟอรัม Debian นี้แนะนำต่อไปนี้:

1) แก้ไขไฟล์ที่/etc/default/grub และแก้ไข GRUB_CMDLINE_LINUXบรรทัดเพื่อให้มีลักษณะดังนี้: GRUB_CMDLINE_LINUX="reboot=bios"

2) วิ่ง: update-grub

หากreboot=biosไม่ได้ผลพวกเขาแนะนำให้ลองใหม่reboot=acpi

ทำงานอย่างใดอย่างหนึ่งเหล่านี้สำหรับคุณ?


ฉันดำเนินการเปลี่ยนแปลงตามที่คุณแนะนำและแจ้งให้คุณทราบในไม่ช้า ขอบคุณ
Reyx_0

น่าเสียดายที่มันไม่ทำงาน และฉันสงสัยว่าปัญหาเกี่ยวข้องกับปัญหาอื่น ๆ ที่ฉันมี (เช่นแล็ปท็อปหยุดพักเป็นช่วง ๆ ในช่วงหยุดพักชั่วคราว): ดูbugzilla.kernel.org/show_bug.cgi?id=102091
Reyx_0

1
ฉันได้พบว่า/sbin/shutdown -r nowงานแทนหรือshutdown -r now reboot
สิบเก้า

ปรับปรุงด้วงใน Centos7 ของฉันบอกว่าคำสั่งที่ไม่พบ
Stiv

@xinthose คำสั่งที่ซับซ้อนทำงานได้ สิ่งที่แปลกก็คือพวกมันชี้ไปที่ไบนารีเดียวกัน ( systemctl) ฉันไม่รู้ว่าทำไม
Junle Li

1

ฉันอยู่ในคอมพิวเตอร์บอร์ดเดี่ยว MIO ที่มีปัญหาเดียวกัน: sudo rebootหรือ [CTRL] + [ALT] + [DEL] นำไปสู่การแขวนที่

สุนัขเฝ้าบ้านไม่ได้หยุด

สิ่งที่กล่าวมาข้างต้นไม่ได้ผลสำหรับฉัน แต่โชคดีที่การรวมกันของพวกเขาทำงาน:

  1. ใช้GRUB_CMDLINE_LINUX="reboot=bios"( reboot=acpiไม่ได้ผลสำหรับฉัน)

  2. ใช้systemctl reboot -iเพื่อรีบูตระบบสำเร็จ ( ลิงก์ )


0

ฉันมีปัญหาเดียวกันอย่างไรก็ตามจ้องจับผิดไม่ใช่ปัญหาของตัวเอง มันเปิดออกได้รับการแก้ไขโดยการตั้งค่าในuse_lvmetad = 0 /etc/lvm/lvm.confอาจเป็นบริการที่แตกต่างในทุกกรณี

systemd-analyze blameถ้าหลังจากนี้คุณพบครั้งบูตยาววิ่ง ในกรณีของฉันฉันพบว่าทำให้เกิดความล่าช้าหนักซึ่งสามารถลดลงโดยการทำงานsystemd-udev-settle.servicesystemctl mask systemd-udev-settle

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