При перезагрузке вылетает сообщение.[Решено]

vladis	# 1 год, 4 месяца назад
Темы: 4 Сообщения: 21 Участник с: 21 января 2020	`wdctl Устр-во: /dev/watchdog0 Identity: iTCO_wdt [версия 2] Таймаут: 30 секунд Оставшееся время: 30 секунд Pre-timeout: 0 секунд FLAG DESCRIPTION STATUS BOOT-STATUS KEEPALIVEPING Keep alive ping reply 1 0 MAGICCLOSE Supports magic close char 0 0 SETTIMEOUT Set timeout (in seconds) 0 0` systemctl shutdown -i пробовал, точнее systemctl -i poweroff, поведение не изменилось. Ссылка на статью, "Ошибка перевода", можно на оригинал дать?

# 1 год, 4 месяца назад

Сообщения: 21

Участник с: 21 января 2020

 wdctl
Устр-во: /dev/watchdog0
Identity:      iTCO_wdt [версия 2]
Таймаут: 30 секунд
Оставшееся время: 30 секунд
Pre-timeout:    0 секунд
FLAG           DESCRIPTION               STATUS BOOT-STATUS
KEEPALIVEPING  Keep alive ping reply          1           0
MAGICCLOSE     Supports magic close char      0           0
SETTIMEOUT     Set timeout (in seconds)       0           0

systemctl shutdown -i пробовал, точнее systemctl -i poweroff, поведение не изменилось. Ссылка на статью, "Ошибка перевода", можно на оригинал дать?

vasek	# 1 год, 4 месяца назад (отредактировано 1 год, 4 месяца назад)
Темы: 47 Сообщения: 11916 Участник с: 17 февраля 2013	vladis Ссылка на статью, "Ошибка перевода", можно на оригинал дать? Исправил - похоже дал нету ссылку .... ... при открытии ссылки нажми крестик если вылезет сообщение ... PS - watchdog мозжно и не причем, проблема может быть связана с другим, что приводит к долгому выключению компа … как пишут Во время обычной работы системы Linux сторожевой таймер периодически ожидает ответа, от системного программного обеспечения. Если система работает правильно, она отправляет контрольный сигнал в течение запланированного периода времени. Однако если система перестает отвечать на запросы из-за проблемы с программным или аппаратным обеспечением, она не может отправить ожидаемый контрольный сигнал. Рекомендую для начала отключить watchdog и узнать как будет выключается система без watchdog. Ошибки не исчезают с опытом - они просто умнеют

vasek

# 1 год, 4 месяца назад (отредактировано 1 год, 4 месяца назад)

Темы: 47

Сообщения: 11916

Участник с: 17 февраля 2013

vladis
Ссылка на статью, "Ошибка перевода", можно на оригинал дать?

Исправил - похоже дал нету ссылку ....
... при открытии ссылки нажми крестик если вылезет сообщение ...

PS - watchdog мозжно и не причем, проблема может быть связана с другим, что приводит к долгому выключению компа … как пишут

Во время обычной работы системы Linux сторожевой таймер периодически ожидает ответа, от системного программного обеспечения. Если система работает правильно, она отправляет контрольный сигнал в течение запланированного периода времени. Однако если система перестает отвечать на запросы из-за проблемы с программным или аппаратным обеспечением, она не может отправить ожидаемый контрольный сигнал.

Рекомендую для начала отключить watchdog и узнать как будет выключается система без watchdog.

Ошибки не исчезают с опытом - они просто умнеют

vladis	# 1 год, 4 месяца назад (отредактировано 1 год, 4 месяца назад)
Темы: 4 Сообщения: 21 Участник с: 21 января 2020	Ну как работает (и для чего нужен) сторожевой таймер, я уже изучил вдоль и поперёк. Отключать не хочу, почему? Потому что система вообще не выключится, как мне кажется. А так проходит 10 мин, да я уже измерил, что соответствует настройке по умолчанию. В /etc/systemd/system.conf есть параметр "#RebootWatchdogSec=10min", по смыслу это он. Вчера перезагружал командой systemctl reboot -f, как мне показалось перезагрузка была нормальной, около 3 мин, да она у меня относительно долгая, ожидает squid (30-40 сек), ещё есть сервисы, которые долго останавливаются, у меня это не десктоп. Обычно от ввода команды до реальной перезагрузки (наблюдаю по светодиодам hdd), проходит 2-3 мин. Судя по логам, проблема с watchdog началась раньше, но до какого-то момента не выливалось в такой длительный процесс. По ссылке, ничего нового не узнал, разве что всё в одном месте. Но в конце есть "4.5. Отключение сторожевого таймера", команда systemctl status watchdog выводит "Unit watchdog.service could not be found." Я не уверен, но пока искал информацию по watchdog, был вариант что это реализовано программно, какой-то службой. Может я чего-то сейчас путаю. Но вещь то полезная. В общем, как интерпретировать информацию от отсутствии watchdog.service, пока не знаю. Но watchdog работает, т.к. через 10 мин. происходит то что должно было произойти. Часть лога, перед командой перезагрузки: дек 24 23:01:01 router CROND[371865]: (root) CMD (run-parts /etc/cron.hourly) дек 24 23:01:01 router crond[371864]: pam_unix(crond:session): session opened for user root(uid=0) by root(uid=0) дек 24 23:01:01 router CROND[371866]: (root) CMD (/usr/bin/netfilter-persistent save >/dev/nul 2>&1) дек 24 23:01:01 router CROND[371863]: (root) CMDEND (run-parts /etc/cron.hourly) дек 24 23:01:02 router CROND[371864]: (root) CMDEND (/usr/bin/netfilter-persistent save >/dev/nul 2>&1) дек 24 23:01:02 router CROND[371864]: pam_unix(crond:session): session closed for user root дек 24 23:01:26 router systemd[1]: Shutting down. дек 24 23:01:27 router systemd[1]: Using hardware watchdog 'iTCO_wdt', version 2, device /dev/watchdog0 дек 24 23:01:27 router systemd[1]: Watchdog running with a timeout of 10min. дек 24 23:01:27 router kernel: watchdog: watchdog0: watchdog did not stop! дек 24 23:01:27 router systemd-shutdown[1]: Using hardware watchdog 'iTCO_wdt', version 2, device /dev/watchdog0 дек 24 23:01:27 router systemd-shutdown[1]: Watchdog running with a timeout of 10min. дек 24 23:01:27 router systemd-shutdown[1]: Syncing filesystems and block devices. дек 24 23:01:27 router systemd-shutdown[1]: Sending SIGTERM to remaining processes... дек 24 23:01:27 router systemd-journald[268]: Received SIGTERM from PID 1 (systemd-shutdow). дек 24 23:01:27 router dnscrypt-proxy[470]: [2023-12-24 23:01:27] [NOTICE] Stopped. дек 24 23:01:27 router dnscrypt-proxy[469]: [2023-12-24 23:01:27] [NOTICE] Stopped. дек 24 23:01:27 router systemd-journald[268]: Journal stopped -- Boot abcdefg8657657abcd -- дек 24 23:04:56 archlinux kernel: microcode: updated early: 0x13 -> 0x22, date = 2019-11-12 Мне кажется, ничего подозрительного. Попытка остановить i2pd: дек 25 21:14:06 router systemd[1]: Stopping I2P Router written in C++... дек 25 20:14:37 router systemd[1]: i2pd.service: State 'stop-sigterm' timed out. Killing. дек 25 20:14:37 router systemd[1]: i2pd.service: Killing process 640 (i2pd) with signal SIGKILL. дек 25 20:15:07 router systemd[1]: i2pd.service: Processes still around after SIGKILL. Ignoring. дек 25 20:15:37 router systemd[1]: i2pd.service: State 'final-sigterm' timed out. Killing. дек 25 20:15:37 router systemd[1]: i2pd.service: Killing process 640 (i2pd) with signal SIGKILL. дек 25 20:16:07 router systemd[1]: i2pd.service: Processes still around after final SIGKILL. Entering failed mode. дек 25 20:16:07 router systemd[1]: i2pd.service: Failed with result 'timeout'. дек 25 20:16:07 router systemd[1]: i2pd.service: Unit process 640 (i2pd) remains running after unit stopped. дек 25 20:16:07 router systemd[1]: Stopped I2P Router written in C++. дек 25 20:16:07 router systemd[1]: i2pd.service: Consumed 44min 50.740s CPU time, 474.0M memory peak, 0B memory swap peak. Возможно проблема в этом?

vladis

# 1 год, 4 месяца назад (отредактировано 1 год, 4 месяца назад)

Темы: 4

Сообщения: 21

Участник с: 21 января 2020

Ну как работает (и для чего нужен) сторожевой таймер, я уже изучил вдоль и поперёк. Отключать не хочу, почему? Потому что система вообще не выключится, как мне кажется. А так проходит 10 мин, да я уже измерил, что соответствует настройке по умолчанию. В /etc/systemd/system.conf есть параметр "#RebootWatchdogSec=10min", по смыслу это он. Вчера перезагружал командой systemctl reboot -f, как мне показалось перезагрузка была нормальной, около 3 мин, да она у меня относительно долгая, ожидает squid (30-40 сек), ещё есть сервисы, которые долго останавливаются, у меня это не десктоп. Обычно от ввода команды до реальной перезагрузки (наблюдаю по светодиодам hdd), проходит 2-3 мин. Судя по логам, проблема с watchdog началась раньше, но до какого-то момента не выливалось в такой длительный процесс. По ссылке, ничего нового не узнал, разве что всё в одном месте. Но в конце есть "4.5. Отключение сторожевого таймера", команда systemctl status watchdog выводит "Unit watchdog.service could not be found." Я не уверен, но пока искал информацию по watchdog, был вариант что это реализовано программно, какой-то службой. Может я чего-то сейчас путаю. Но вещь то полезная. В общем, как интерпретировать информацию от отсутствии watchdog.service, пока не знаю. Но watchdog работает, т.к. через 10 мин. происходит то что должно было произойти.

Часть лога, перед командой перезагрузки:

дек 24 23:01:01 router CROND[371865]: (root) CMD (run-parts /etc/cron.hourly)
дек 24 23:01:01 router crond[371864]: pam_unix(crond:session): session opened for user root(uid=0) by root(uid=0)
дек 24 23:01:01 router CROND[371866]: (root) CMD (/usr/bin/netfilter-persistent save >/dev/nul 2>&1)
дек 24 23:01:01 router CROND[371863]: (root) CMDEND (run-parts /etc/cron.hourly)
дек 24 23:01:02 router CROND[371864]: (root) CMDEND (/usr/bin/netfilter-persistent save >/dev/nul 2>&1)
дек 24 23:01:02 router CROND[371864]: pam_unix(crond:session): session closed for user root
дек 24 23:01:26 router systemd[1]: Shutting down.
дек 24 23:01:27 router systemd[1]: Using hardware watchdog 'iTCO_wdt', version 2, device /dev/watchdog0
дек 24 23:01:27 router systemd[1]: Watchdog running with a timeout of 10min.
дек 24 23:01:27 router kernel: watchdog: watchdog0: watchdog did not stop!
дек 24 23:01:27 router systemd-shutdown[1]: Using hardware watchdog 'iTCO_wdt', version 2, device /dev/watchdog0
дек 24 23:01:27 router systemd-shutdown[1]: Watchdog running with a timeout of 10min.
дек 24 23:01:27 router systemd-shutdown[1]: Syncing filesystems and block devices.
дек 24 23:01:27 router systemd-shutdown[1]: Sending SIGTERM to remaining processes...
дек 24 23:01:27 router systemd-journald[268]: Received SIGTERM from PID 1 (systemd-shutdow).
дек 24 23:01:27 router dnscrypt-proxy[470]: [2023-12-24 23:01:27] [NOTICE] Stopped.
дек 24 23:01:27 router dnscrypt-proxy[469]: [2023-12-24 23:01:27] [NOTICE] Stopped.
дек 24 23:01:27 router systemd-journald[268]: Journal stopped
-- Boot abcdefg8657657abcd --
дек 24 23:04:56 archlinux kernel: microcode: updated early: 0x13 -> 0x22, date = 2019-11-12

Мне кажется, ничего подозрительного. Попытка остановить i2pd:

дек 25 21:14:06 router systemd[1]: Stopping I2P Router written in C++...
дек 25 20:14:37 router systemd[1]: i2pd.service: State 'stop-sigterm' timed out. Killing.
дек 25 20:14:37 router systemd[1]: i2pd.service: Killing process 640 (i2pd) with signal SIGKILL.
дек 25 20:15:07 router systemd[1]: i2pd.service: Processes still around after SIGKILL. Ignoring.
дек 25 20:15:37 router systemd[1]: i2pd.service: State 'final-sigterm' timed out. Killing.
дек 25 20:15:37 router systemd[1]: i2pd.service: Killing process 640 (i2pd) with signal SIGKILL.
дек 25 20:16:07 router systemd[1]: i2pd.service: Processes still around after final SIGKILL. Entering failed mode.
дек 25 20:16:07 router systemd[1]: i2pd.service: Failed with result 'timeout'.
дек 25 20:16:07 router systemd[1]: i2pd.service: Unit process 640 (i2pd) remains running after unit stopped.
дек 25 20:16:07 router systemd[1]: Stopped I2P Router written in C++.
дек 25 20:16:07 router systemd[1]: i2pd.service: Consumed 44min 50.740s CPU time, 474.0M memory peak, 0B memory swap peak.

Возможно проблема в этом?

igorog	# 1 год, 4 месяца назад
Темы: 15 Сообщения: 190 Участник с: 22 июля 2018	vladis Потому что система вообще не выключится Отключил у себя сто лет назад - никаких проблем. ИМХО эта собака нужна, как собаке пятая нога. )) Давайте жить дружно! :-)

vladis	# 1 год, 4 месяца назад
Темы: 4 Сообщения: 21 Участник с: 21 января 2020	Не согласен, в моём случае это не десктоп (который вы можете проконтролировать) и если что-то произойдёт, то будет не приятно. Тем более сейчас именно по нему и перезагрузка происходит, а так зависла бы система и отвечает только на кнопку сброса. Я кстати выяснил причину, ядра 6.6.х у меня вызывают ту ошибку из последнего моего сообщения, точнее поведение некоторых служб. Но на ядре 6.5.9 (у меня это последнее из 6.5) проблем нет. На этом ядре, тоже есть сообщение про watchdog, но система по командам успешно перезагружается, не "дожидаясь" срабатывания watchdog.

vladis

# 1 год, 4 месяца назад

Темы: 4

Сообщения: 21

Участник с: 21 января 2020

Не согласен, в моём случае это не десктоп (который вы можете проконтролировать) и если что-то произойдёт, то будет не приятно. Тем более сейчас именно по нему и перезагрузка происходит, а так зависла бы система и отвечает только на кнопку сброса. Я кстати выяснил причину, ядра 6.6.х у меня вызывают ту ошибку из последнего моего сообщения, точнее поведение некоторых служб. Но на ядре 6.5.9 (у меня это последнее из 6.5) проблем нет. На этом ядре, тоже есть сообщение про watchdog, но система по командам успешно перезагружается, не "дожидаясь" срабатывания watchdog.