it-swarm.com.de

Meldung beim Herunterfahren: Watchdog hat nicht aufgehört!

Beim Herunterfahren bekomme ich oft die Nachricht

watchdog did not stop!

und dann friert der Laptop nach wenigen anderen Leitungen ein, ohne herunterzufahren.

Irgendeine Idee, wie man das behebt? In letzter Zeit kam es sehr oft vor, normalerweise, wenn der Laptop einige Zeit eingeschaltet war.

Ich verwende Debian 8 auf einem Asus UX32LA

Ich habe diese systemd-Datei gefunden (sie zeigt einen Konflikt mit der Datei shutdown.target), wenn dies hilfreich sein kann. Mein Eindruck ist, dass das Problem von einem Problem abhängt, das von mir kommt, als ich versuchte, die Hintergrundbeleuchtung zu reparieren (was eigentlich nur mit dem Grub-Parameter "acpi_osi =" funktioniert).

[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
20
Reyx_0

Die Zeile watchdog did not stop! Ist normal. systemd setzt einen " Hardware Watchdog " - Timer als ausfallsicher, um sicherzustellen, dass der Computer nach dem angegebenen Zeitraum immer noch heruntergefahren wird, wenn der normale Herunterfahrvorgang einfriert/fehlschlägt. Dieser Zeitraum ist in der Variablen ShutdownWatchdogSec= In der Datei /etc/systemd/system.conf Definiert. Hier ist die Beschreibung von die Dokumente :

RuntimeWatchdogSec =, ShutdownWatchdogSec =

Konfigurieren Sie den Hardware-Watchdog zur Laufzeit und beim Neustart. Nimmt einen Timeout-Wert in Sekunden an (oder in anderen Zeiteinheiten, wenn "ms", "min", "h", "d", "w" angehängt sind). Wenn RuntimeWatchdogSec = auf einen Wert ungleich Null gesetzt ist, wird die Watchdog-Hardware (/ dev/watchdog) so programmiert, dass das System automatisch neu gestartet wird, wenn es nicht innerhalb des angegebenen Zeitlimits kontaktiert wird. Der Systemmanager stellt sicher, dass er mindestens einmal in der Hälfte des angegebenen Zeitlimits kontaktiert wird. Für diese Funktion muss ein Hardware-Watchdog-Gerät vorhanden sein, wie dies üblicherweise bei eingebetteten Systemen und Serversystemen der Fall ist. Nicht alle Hardware-Watchdogs ermöglichen die Konfiguration des Neustart-Timeouts. In diesem Fall wird das nächstgelegene verfügbare Timeout ausgewählt. ShutdownWatchdogSec = kann verwendet werden, um den Hardware-Watchdog zu konfigurieren, wenn das System zum Neustart aufgefordert wird. Es fungiert als Sicherheitsnetz, um sicherzustellen, dass der Neustart auch dann erfolgt, wenn bei einem sauberen Neustart eine Zeitüberschreitung auftritt. Standardmäßig ist RuntimeWatchdogSec = standardmäßig 0 (aus) und ShutdownWatchdogSec = 10 min. Diese Einstellungen haben keine Auswirkung, wenn kein Hardware-Watchdog verfügbar ist.

Wie Sie bereits angedeutet haben, ist es wahrscheinlich, dass Ihr eigentliches Problem mit dem Ändern der ACPI-Einstellungen zusammenhängt. Die Antworten auf dieser Debian-Forenthread schlagen Folgendes vor:

1) Bearbeiten Sie die Datei unter /etc/default/grub Und bearbeiten Sie die Zeile GRUB_CMDLINE_LINUX So: GRUB_CMDLINE_LINUX="reboot=bios"

2) run: update-grub

Wenn reboot=bios Nicht funktioniert, empfehlen sie, es erneut mit reboot=acpi Zu versuchen.

Arbeiten beide für Sie?

16
J. Taylor

Ich bin auf einem MIO-Einplatinencomputer mit dem gleichen Problem: Sudo reboot oder [STRG] + [ALT] + [ENTF] führt zum Hängen an

wachhund hörte nicht auf

Keiner der oben genannten Punkte hat für mich funktioniert, aber zum Glück hat eine Kombination von ihnen den Job gemacht:

  1. Verwenden GRUB_CMDLINE_LINUX="reboot=bios" (reboot=acpi hat bei mir nicht funktioniert)

  2. Verwenden systemctl reboot -i, um das System erfolgreich neu zu starten. ( Link )

1
domih

Ich hatte das gleiche Problem, aber Watchdog ist nicht das Problem selbst. Es stellte sich heraus, dass dies behoben wurde, indem use_lvmetad = 0 In /etc/lvm/lvm.conf Eingestellt wurde. Könnten auf jeden Fall andere Dienste sein.

Wenn danach lange Startzeiten auftreten, führen Sie systemd-analyze blame Aus. In meinem Fall stellte ich fest, dass systemd-udev-settle.service Starke Verzögerungen verursachte, die durch Ausführen von systemctl mask systemd-udev-settle Abgemildert werden können.

0
Thomas G.