wiadomość przy wyłączaniu: organ nadzorczy nie zatrzymał się!

Podczas zamknięcia często dostaję wiadomość

watchdog did not stop!

a następnie laptop zawiesza się po kilku innych liniach bez wyłączania się.

Masz pomysł, jak to naprawić? Ostatnio zdarzało się to bardzo często, zwykle kiedy laptop był włączony przez pewien czas.

Używam Debian 8 na Asus UX32LA

Znalazłem ten plik systemowy (pokazuje konflikt z shutdown.target), jeśli może pomóc. Mam wrażenie, że problem zależy od jakiegoś problemu pochodzącego ode mnie, który próbuje naprawić podświetlenie (co w rzeczywistości działa tylko z grubym paramenterem „acpi_osi =”)

[Unit]
Description=Load/Save Screen Backlight Brightness of %i
Documentation=man:[email protected](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

watchdog did not stop!Linia jest normalne zachowanie. systemdustawia licznik czasu „ sprzętowego nadzoru ” jako zabezpieczenie przed awarią, aby upewnić się, że jeśli normalny proces zamykania zawiesi się lub nie powiedzie, komputer nadal będzie się wyłączał po upływie określonego czasu. Ten okres jest zdefiniowany w zmiennej ShutdownWatchdogSec=w pliku /etc/systemd/system.conf. Oto opis z dokumentów :

RuntimeWatchdogSec =, ShutdownWatchdogSec =

Skonfiguruj sprzętowy organ nadzorczy w czasie wykonywania i podczas ponownego uruchamiania. Przyjmuje wartość limitu czasu w sekundach (lub w innych jednostkach czasu, jeśli jest uzupełniona „ms”, „min”, „h”, „d”, „w”). Jeśli RuntimeWatchdogSec = jest ustawione na wartość niezerową, sprzęt watchdog (/ dev / watchdog) zostanie zaprogramowany do automatycznego ponownego uruchomienia systemu, jeśli nie skontaktuje się z nim w określonym przedziale czasu. Menedżer systemu dopilnuje, aby skontaktować się z nim co najmniej raz na pół określonego czasu oczekiwania. Ta funkcja wymaga obecności sprzętowego urządzenia nadzorującego, jak to zwykle ma miejsce w systemach wbudowanych i serwerowych. Nie wszystkie sprzętowe watchdogi umożliwiają konfigurację limitu czasu ponownego uruchomienia, w którym to przypadku wybierany jest najbliższy dostępny limit czasu. ShutdownWatchdogSec = może być użyty do skonfigurowania sprzętowego watchdoga, gdy system zostanie poproszony o ponowne uruchomienie. Działa jako siatka bezpieczeństwa, aby zapewnić, że ponowne uruchomienie nastąpi, nawet jeśli próba czystego ponownego uruchomienia przekroczy limit czasu. Domyślnie RuntimeWatchdogSec = domyślnie 0 (wyłączone), a ShutdownWatchdogSec = 10 minut. Te ustawienia nie działają, jeśli sprzętowy watchdog nie jest dostępny.

Jak już wspomniałeś, wydaje się prawdopodobne, że faktyczny problem związany jest ze zmianą ustawień ACPI. Odpowiedzi w tym wątku na forum Debiana sugerują, co następuje:

1) Edytuj plik /etc/default/grub i edytuj GRUB_CMDLINE_LINUXlinię, aby wyglądała następująco: GRUB_CMDLINE_LINUX="reboot=bios"

2) uruchom: update-grub

Jeśli reboot=biosnie działa, sugerują ponowienie próbyreboot=acpi

Czy któryś z nich działa dla Ciebie?

Jestem na komputerze jednopłytkowym MIO z tym samym problemem: sudo rebootlub [CTRL] + [ALT] + [DEL] prowadzi do zawieszenia się na

organ nadzoru nie zatrzymał się

Żadne z powyższych nie działało dla mnie, ale na szczęście ich kombinacja wykonała zadanie:

1. Użyj GRUB_CMDLINE_LINUX="reboot=bios"( reboot=acpinie działało dla mnie)

2. Użyj systemctl reboot -i, aby pomyślnie zrestartować system. ( link )

Miałem ten sam problem, jednak watchdog nie jest sam w sobie problemem. Okazało się to być ustalone przez ustawienie use_lvmetad = 0w /etc/lvm/lvm.conf. W każdym razie mogą to być różne usługi.

Jeśli po tym wystąpią długie czasy uruchamiania, uruchom systemd-analyze blame. W moim przypadku stwierdziłem, że systemd-udev-settle.servicespowodowało to duże opóźnienia, które można złagodzić, uruchamiając systemctl mask systemd-udev-settle.