повідомлення при відключенні: сторожовий пес не зупинився!

При відключенні я часто отримую повідомлення

watchdog did not stop!

а потім ноутбук замерзає після кількох інших ліній, не вимикаючись.

Будь-яка ідея, як це виправити? Останнім часом це траплялося дуже часто, як правило, коли ноутбук був увімкнений деякий час.

Я використовую Debian 8 на Asus UX32LA

Я знайшов цей системний файл (він показує конфлікт із shutdown.target), якщо він може допомогти. Моє враження полягає в тому, що проблема залежить від проблеми, яка надходить до мене, намагаючись виправити підсвічування (що насправді працює лише з параметром 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
джерело

Чи можете ви спробувати видалити "rhgb silent" з завантажувального cmdline і потім подивитися, що відбувається?

— шубхам

Саме те, що я збирався запропонувати. "rhgb silent" пригнічує повідомлення при завантаженні / відключенні, що може бути тут дуже корисним.

— Тім С.

немає "rhgb silent" в / etc / default / grub (а оновлення оновлено)

— Reyx_0

У Debian еквівалентними варіантами для видалення є "тихий сплеск".

— telcoM

Відповіді:

watchdog did not stop!Лінія є нормальною поведінкою. systemdвстановлює таймер " апаратної сторожової " як помилку, щоб гарантувати, що якщо нормальний процес відключення заморозиться / вийде з ладу, комп'ютер все ще відключиться через визначений проміжок часу. Цей період часу визначений у змінній ShutdownWatchdogSec=у файлі /etc/systemd/system.conf. Ось опис документів :

RuntimeWatchdogSec =, ShutdownWatchdogSec =

Налаштуйте апаратну сторожову службу під час виконання та перезавантаження. Приймає значення тайм-ауту в секундах (або в інших одиницях часу, якщо вони суфіксировані з "ms", "min", "h", "d", "w"). Якщо для RuntimeWatchdogSec = встановлено ненульове значення, апаратне забезпечення сторожової собаки (/ dev / watchdog) буде запрограмовано для автоматичної перезавантаження системи, якщо з нею не звертається протягом визначеного інтервалу очікування. Менеджер системи забезпечить зв’язок з ним принаймні раз на половину зазначеного інтервалу очікування. Ця функція вимагає наявності апаратного сторожового пристрою, як це часто буває у вбудованих та серверних системах. Не всі апаратні сторожові собаки дозволяють конфігурувати час очікування перезавантаження, і в цьому випадку вибирається найближчий доступний час очікування. ShutdownWatchdogSec = може бути використаний для налаштування апаратної сторожової собаки, коли система просить перезавантажити. Він працює як захисна мережа для того, щоб перезавантаження відбулося навіть у тому випадку, якщо час чистої спроби перезавантаження закінчиться. За замовчуванням RuntimeWatchdogSec = за замовчуванням до 0 (вимкнено), а ShutdownWatchdogSec = до 10 хв. Ці параметри не впливають, якщо апаратний сторожовий дог недоступний.

Як ви вказали, можливо, ваша реальна проблема пов'язана зі зміною налаштувань ACPI. Відповіді на тему форуму Debian пропонують наступне:

1) Відредагуйте файл у /etc/default/grub та відредагуйте GRUB_CMDLINE_LINUXрядок таким чином: GRUB_CMDLINE_LINUX="reboot=bios"

2) запустити: update-grub

Якщо reboot=biosце не працює, вони пропонують повторити спробуreboot=acpi

Чи працює одне з вас?

— Дж. Тейлор
джерело

Я впровадив запропоновані вами зміни, і незабаром повідомляю вас. Спасибі

— Reyx_0

на жаль, це не працює. і я підозрюю, що ця проблема пов'язана з цією іншою проблемою, яку я також маю (тобто ноутбук спорадично зависає при

— зупинці

Я виявив, що /sbin/shutdown -r nowпрацює замість shutdown -r nowабо reboot.

— xinthose

update-grub на моєму Centos7 говорить, що команду не знайдено

— stiv

@xinthose Ця хитра команда працює. Дивна річ у тому, що вони вказують на той самий бінарний ( systemctl), я поняття не маю чому.

— Джунле Лі

Я на одному бортовому комп'ютері MIO з тією ж проблемою: sudo rebootабо [CTRL] + [ALT] + [DEL] призводить до зависання на

сторожовий пес не зупинявся

Ніщо з перерахованого вище не працювало для мене, але, на щастя, поєднання їх зробило роботу:

Використовувати GRUB_CMDLINE_LINUX="reboot=bios"( reboot=acpiне працювало для мене)
Використовуйте systemctl reboot -iдля успішного перезавантаження системи. ( посилання )

— доміх
джерело

У мене був той самий випуск, однак сторожовий не сам випуск. Виявилося , що можна вирішити, встановивши use_lvmetad = 0в /etc/lvm/lvm.conf. У будь-якому випадку можуть бути різні послуги.

Якщо після цього ви відчуваєте довгі рази завантаження, запустіть systemd-analyze blame. У моєму випадку я виявив, що systemd-udev-settle.serviceспричинив великі затримки, які можна пом'якшити бігом systemctl mask systemd-udev-settle.

— Томас Г.
джерело