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 savoir comment régler ça? 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: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

— Reyx_0
source

Pouvez-vous essayer de supprimer «rhgb quiet» de la cmdline de démarrage, puis voir ce qui se passe?

— shubham

Exactement ce que j'allais suggérer. "rhgb quiet" supprime les messages au démarrage / arrêt qui pourraient être très utiles ici.

— Tim S.

il n'y a pas de "rhgb quiet" dans / etc / default / grub (et grub est mis à jour)

— Reyx_0

Dans Debian, les options équivalentes à supprimer sont "splash silencieux".

— telcoM

Réponses:

La watchdog did not stop!ligne est un comportement normal. systemddéfinit une minuterie de " surveillance du matériel " comme une 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=du fichier /etc/systemd/system.conf. Voici la description des documents :

RuntimeWatchdogSec =, ShutdownWatchdogSec =

Configurez le chien de garde matériel à 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 temporisation 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 de configurer le 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 la GRUB_CMDLINE_LINUXligne pour qu'elle ressemble à ceci: GRUB_CMDLINE_LINUX="reboot=bios"

2) exécuter: update-grub

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

Est-ce que l'un de ces travaux fonctionne pour vous?

— J. Taylor
source

J'ai mis en œuvre les modifications que vous avez suggérées et je vous en informerai bientôt. Merci

— Reyx_0

Malheureusement ça ne marche pas. et je soupçonne que le problème est lié à cet autre problème que j'ai également (c'est-à-dire que l'ordinateur portable se bloque sporadiquement en cas de suspension): voir bugzilla.kernel.org/show_bug.cgi?id=102091

— Reyx_0

J'ai trouvé que cela /sbin/shutdown -r nowfonctionne au lieu de shutdown -r nowou reboot.

— xinthose

update-grub sur mon Centos7 dit que la commande est introuvable

— stiv

@xinthose Cette commande délicate fonctionne. Ce qui est étrange, c'est qu'ils pointent vers le même binaire ( systemctl), je ne sais pas pourquoi.

— Junle Li

Je suis sur un ordinateur monocarte MIO avec le même problème: sudo rebootou [CTRL] + [ALT] + [DEL] entraîne un blocage à

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:

Utilisation GRUB_CMDLINE_LINUX="reboot=bios"( reboot=acpin'a pas fonctionné pour moi)
Utilisez systemctl reboot -i, pour redémarrer avec succès le système. ( lien )

— domih
source

J'ai eu le même problème, cependant, le chien de garde n'est pas le problème lui-même. Il est avéré être fixé par la mise use_lvmetad = 0en /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 constaté que cela systemd-udev-settle.servicecausait de gros retards, qui peuvent être atténués en exécutant systemctl mask systemd-udev-settle.

— Thomas G.
source