web-dev-qa-db-fra.com

message à l'arrêt: le chien de garde ne s'est pas arrêté!

À l'arrêt, je reçois souvent le message

watchdog did not stop!

puis l'ordinateur portable se fige après quelques autres lignes sans s'éteindre.

Une idée pour réparer ceci? Récemment, cela s'est produit très souvent, généralement lorsque l'ordinateur portable a été allumé pendant un certain temps.

J'utilise Debian 8 sur un Asus UX32LA

J'ai trouvé ce fichier systemd (il montre un conflit avec le shutdown.target), si cela peut aider. Mon impression est que le problème dépend d'un problème venant de moi essayant de réparer le rétro-éclairage (qui ne fonctionne en fait qu'avec le paramètre grub "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
shutdownacpiwatchdogacpid
20
Reyx_0

Le watchdog did not stop! la ligne est un comportement normal. systemd définit une minuterie " surveillance du matériel " comme sécurité intégrée, pour garantir que si le processus d'arrêt normal se bloque/échoue, l'ordinateur s'arrêtera toujours après la période spécifiée. Cette période est définie dans la variable ShutdownWatchdogSec= dans le fichier /etc/systemd/system.conf. Voici la description de les docs :

RuntimeWatchdogSec =, ShutdownWatchdogSec =

Configurez le chien de garde matériel lors de l'exécution et au redémarrage. Prend une valeur de délai d'attente en secondes (ou dans d'autres unités de temps si elles sont suffixées avec "ms", "min", "h", "d", "w"). Si RuntimeWatchdogSec = est défini sur une valeur non nulle, le matériel du chien de garde (/ dev/watchdog) sera programmé pour redémarrer automatiquement le système s'il n'est pas contacté dans l'intervalle de délai spécifié. Le gestionnaire du système veillera à le contacter au moins une fois dans la moitié de l'intervalle de délai spécifié. Cette fonctionnalité nécessite la présence d'un dispositif de surveillance matériel, comme c'est généralement le cas dans les systèmes embarqués et serveurs. Tous les chiens de garde matériels ne permettent pas la configuration du délai de redémarrage, auquel cas le délai disponible le plus proche est sélectionné. ShutdownWatchdogSec = peut être utilisé pour configurer le chien de garde matériel lorsque le système est invité à redémarrer. Il fonctionne comme un filet de sécurité pour garantir que le redémarrage a lieu même si une nouvelle tentative de redémarrage arrive à expiration. Par défaut, RuntimeWatchdogSec = par défaut à 0 (désactivé) et ShutdownWatchdogSec = à 10 min. Ces paramètres n'ont aucun effet si aucun chien de garde matériel n'est disponible.

Il semble probable, comme vous l'avez indiqué, que votre problème réel soit lié à la modification des paramètres ACPI. Les réponses sur ce fil de discussion Debian suggèrent ce qui suit:

1) Modifiez le fichier à /etc/default/grub et modifiez le GRUB_CMDLINE_LINUX ligne pour ressembler à ceci: GRUB_CMDLINE_LINUX="reboot=bios"

2) exécuter: update-grub

Si reboot=bios ne fonctionne pas, ils suggèrent de réessayer avec reboot=acpi

Est-ce que l'un ou l'autre de ces éléments fonctionne pour vous?

16
J. Taylor

Je suis sur un ordinateur monocarte MIO avec le même problème: Sudo reboot ou [CTRL] + [ALT] + [DEL] entraîne une suspension à

chien de garde ne s'est pas arrêté

Rien de ce qui précède n'a fonctionné pour moi, mais heureusement, une combinaison d'entre eux a fait le travail:

  1. Utilisation GRUB_CMDLINE_LINUX="reboot=bios" (reboot=acpi N'a pas travaillé pour moi)

  2. Utilisation systemctl reboot -i, pour redémarrer avec succès le système. ( lien )

1
domih

J'ai eu le même problème, cependant, le chien de garde n'est pas le problème lui-même. Il s'est avéré être corrigé en définissant use_lvmetad = 0 dans /etc/lvm/lvm.conf. Peut-être des services différents dans tous les cas.

Si, après cela, vous rencontrez de longs temps de démarrage, exécutez systemd-analyze blame. Dans mon cas, j'ai trouvé que systemd-udev-settle.service a causé de gros retards, qui peuvent être atténués en exécutant systemctl mask systemd-udev-settle.

0
Thomas G.