messaggio allo spegnimento: il watchdog non si è fermato!

All'arresto ricevo spesso il messaggio

watchdog did not stop!

e poi il laptop si blocca dopo poche altre linee senza spegnersi.

Qualche idea su come risolvere questo problema? Di recente è successo molto spesso, di solito quando il laptop è stato acceso per qualche tempo.

Sto usando Debian 8 su un Asus UX32LA

Ho trovato questo file systemd (mostra un conflitto con shutdown.target), se può aiutare. La mia impressione è che il problema dipenda da qualche problema che proviene da me cercando di riparare la retroilluminazione (che in realtà funziona solo con il paramenter 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
fonte

Puoi provare a rimuovere "rhgb quiet" dal boot cmdline e poi vedere cosa succede?

— Shubham,

Esattamente quello che stavo per suggerire. "rhgb quiet" elimina i messaggi all'avvio / spegnimento che potrebbero essere molto utili qui.

— Tim S.

non c'è "rhgb quiet" in / etc / default / grub (e grub è aggiornato)

— Reyx_0

In Debian, le opzioni equivalenti da rimuovere sono "quiet splash".

— telcoM

Risposte:

La watchdog did not stop!linea è un comportamento normale. systemdimposta un timer " watchdog hardware " come fail-safe, per garantire che, se il normale processo di arresto si blocca / non funziona, il computer continuerà a spegnersi dopo il periodo di tempo specificato. Questo periodo di tempo è definito nella variabile ShutdownWatchdogSec=nel file /etc/systemd/system.conf. Ecco la descrizione dai documenti :

RuntimeWatchdogSec =, ShutdownWatchdogSec =

Configurare il watchdog hardware in fase di runtime e al riavvio. Accetta un valore di timeout in secondi (o in altre unità di tempo se suffisso "ms", "min", "h", "d", "w"). Se RuntimeWatchdogSec = è impostato su un valore diverso da zero, l'hardware del watchdog (/ dev / watchdog) verrà programmato per riavviare automaticamente il sistema se non viene contattato entro l'intervallo di timeout specificato. Il gestore del sistema assicurerà di contattarlo almeno una volta a metà dell'intervallo di timeout specificato. Questa funzione richiede la presenza di un dispositivo watchdog hardware, come spesso accade nei sistemi embedded e server. Non tutti i watchdog hardware consentono la configurazione del timeout di riavvio, nel qual caso viene selezionato il timeout più vicino disponibile. ShutdownWatchdogSec = può essere utilizzato per configurare il watchdog hardware quando viene richiesto il riavvio del sistema. Funziona come una rete di sicurezza per garantire che il riavvio avvenga anche se un tentativo di riavvio pulito scade. Per impostazione predefinita, RuntimeWatchdogSec = predefinito su 0 (disattivato) e ShutdownWatchdogSec = su 10min. Queste impostazioni non hanno effetto se un watchdog hardware non è disponibile.

Sembra probabile, come hai indicato, che il tuo vero problema sia legato alla modifica delle impostazioni ACPI. Le risposte su questo thread del forum Debian suggeriscono quanto segue:

1) Modifica il file in /etc/default/grub e modifica la GRUB_CMDLINE_LINUXlinea in questo modo: GRUB_CMDLINE_LINUX="reboot=bios"

2) eseguire: update-grub

Se reboot=biosnon funziona, suggeriscono di riprovarereboot=acpi

Uno di questi funziona per te?

— J. Taylor
fonte

Ho implementato le modifiche che hai suggerito e ti informerò presto. Grazie

— Reyx_0 il

purtroppo non funziona. e sospetto che il problema sia legato a questo altro problema che ho anche (cioè il laptop si blocca sporadicamente in caso di sospensione): vedi bugzilla.kernel.org/show_bug.cgi?id=102091

— Reyx_0

Ho scoperto che /sbin/shutdown -r nowfunziona invece di shutdown -r nowo reboot.

— xinthose

update-grub sul mio Centos7 dice che il comando non è stato trovato

— stiv

@xinthose Quel comando complicato funziona. La cosa strana è che stanno indicando lo stesso binario ( systemctl), non ho idea del perché.

— Junle Li

Sono su un computer MIO a scheda singola con lo stesso problema: sudo rebootoppure [CTRL] + [ALT] + [DEL] porta a rimanere in sospeso

il cane da guardia non si è fermato

Nessuna delle precedenti ha funzionato per me, ma per fortuna una combinazione di loro ha fatto il lavoro:

Usa GRUB_CMDLINE_LINUX="reboot=bios"( reboot=acpinon ha funzionato per me)
Utilizzare systemctl reboot -i, per riavviare correttamente il sistema. ( link )

— domih
fonte

Ho avuto lo stesso problema, tuttavia, il cane da guardia non è il problema stesso. Si è rivelato essere risolto impostando use_lvmetad = 0in /etc/lvm/lvm.conf. Potrebbero essere servizi diversi in ogni caso.

Se, dopo questo, si verificano lunghi tempi di avvio, eseguire systemd-analyze blame. Nel mio caso, ho scoperto che ciò ha systemd-udev-settle.servicecausato gravi ritardi, che possono essere mitigati correndo systemctl mask systemd-udev-settle.

— Thomas G.
fonte