Система виснет редко, но метко

Всем привет,

Раз в пару месяцев десктоп виснет. Интерфейс замораживается, указатель мыши не двигается. Помогает только хард-ресет (который, конечно, вреден для системы). Раньше (много лет) такого не было. Позавчера вот всё зависло через минут 5 после запуска (был открыт браузер с онлайн-музыкой и всё).

Система: Arch+Cinnamon.
Памяти 8гб, так что проблема вряд ли в её размере.
Куда можно копнуть? Вряд ли же есть лог такого рода проблем? (т.к. если всё зависает, то и понять, что произошла ошибка, система не может).

Забыл сказать, что виснет не только DE, но и система в целом, т.к. на Ctrl+Alt+F1 тоже не отзывается.
из за чего угодно может виснуть

больше похоже на проблему с железом, возможно система разогнана, в любом случае стоит понизить частоты и посмотреть чего будет
так-же стоит передёрнуть все разъёмы, и проверить напряжения выдаваемые БП + проверить конденсаторы на вздутие

не из за железа, подобное у меня было когда xorg новый обновил,
как вариант попробовать базовые пакеты типа ядра, xorg, видеодрова даунгрейднуть

ну journalctl глянуть на предмет событий перед зависанием
slend3r
Помогает только хард-ресет (который, конечно, вреден для системы)
Есть клавиша SysRq (PrtSc - Print Screen) - это единственная клавиша, имеющая связь с ядром и если ядро не зависло (а оно виснет редко), то для начала следет пробовать комбинацию клавиш :
Перегрузка:  Alt + SysRq + R + E + I + S + U + B
Выключение:  Alt + SysRq + R + E + I + S + U + O
Но чтобы это задействовать, нужно заранее установить значение kernel.sysrq=1

slend3r
виснет не только DE, но и система в целом, т.к. на Ctrl+Alt+F1 тоже не отзывается
Можно попробовать узнать информацию о памяти, процессах и др., используя комбинации Alt+SysRq+KEY, где возможные значения KEY
f - вызов oom_kill (убъет жрущий процесс, потребуется несколько минут) ... в случае нехватки памяти
m - вся инфа о памяти
t - вся инфа о запущенных процессах
w -  список всех заблокированных, ждущих окончания ввода-вывода задач
Не всегда, но шанс имеется, что после ввода этих комбинаций информация отразится в journal и ее можно будет посмотреть при следующей загрузке.
Ну а если не отразится, то нужно использовать утилиты, которые с указанной периодичностью фиксируют определенные параметры, которые можно посмотреть при следующей загрузке на момент перед зависанием.
Ошибки не исчезают с опытом - они просто умнеют
Спасибо, так и сделаю!
Сегодня опять всё подвисло.
На Alt+SysRq+... не откликается (ни перезагрузка, ни логгирование в журнал не работают...)
Перезагрузил - Alt+SysRq+m работает

Журнал проверял с помощью
sudo journalctl --since "40 min ago"
Вывод такой:
дек 10 11:13:08 arch systemd[1]: Starting Cleanup of Temporary Directories...
дек 10 11:13:08 arch systemd[1]: systemd-tmpfiles-clean.service: Succeeded.
дек 10 11:13:08 arch systemd[1]: Finished Cleanup of Temporary Directories.
дек 10 11:13:08 arch audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-tmpfiles-clean comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
дек 10 11:13:08 arch audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-tmpfiles-clean comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
дек 10 11:13:08 arch kernel: audit: type=1130 audit(1607587988.091:108): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-tmpfiles-clean comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr>
дек 10 11:13:08 arch kernel: audit: type=1131 audit(1607587988.091:109): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-tmpfiles-clean comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr>
-- Boot c696bad97169492cbe36b5eae07cdea7 --
дек 10 11:48:57 arch kernel: microcode: microcode updated early to revision 0x21, date = 2019-02-13
дек 10 11:48:57 arch kernel: Linux version 5.9.12-arch1-1 (linux@archlinux) (gcc (GCC) 10.2.0, GNU ld (GNU Binutils) 2.35.1) #1 SMP PREEMPT Wed, 02 Dec 2020 16:14:56 +0000

Зависание при этом произошло в 11:16. При этом был открыт firefox, скачивалось несколько больших файлов.

Видимо, проблема действительно с железом?
slend3r
На Alt+SysRq+… не откликается (ни перезагрузка, ни логгирование в журнал не работают…)
Для начала - на нормальной системе эти комбинации работают?
Перегрузка:  Alt + SysRq + R + E + I + S + U + B
Ошибки не исчезают с опытом - они просто умнеют
vasek,
да, только что проверил
slend3r
да, только что проверил
Далее, нужно точно знать работает ли эта комбинация при зависании и исходя из этого сделать заключение
- если не работает, то виснет ядро .... но это маловероятно, если ядро стандартное
- если работает, значит ядро не причем и нужно пробовать другие комбинации. А чтобы понять, как они работают, то рекомендую запустить journalctl -f (просмотр логов в режиме on-line) и смотри вывод после каждого нажатия, чтобы понять, какой должен быть вывод. Эти логи можно смотреть и после перегрузки - поэтому перегрузись и посмотри как они выглядят и как их можно найти. Это я к тому, что нужно подготовиться к зависанию, чтобы четко знал, что нажимать и что потом должен увидеть в логах.
Например, я запустил journalctl -f и запускаю следующие комбинации
PS - удобнее нажимать так - правой рукой большим пальцем нажимаем правый Alt (alt gr), а другим удобным пальцем нажимаем SysRq (prt sc) .. а пальцем левой руки нажимаем нужную KEY, например h ... (что равносильно –help - покажет возможные комбинации и их назначение)
- Alt+SysRq+h
дек 10 12:59:43 arch kernel: sysrq: HELP : loglevel(0-9) reboot(b) crash(c) terminate-all-tasks(e) memory-full-oom-kill(f) kill-all-tasks(i) thaw-filesystems(j) sak(k) show-backtrace-all-active-cpus(l) show-memory-usage(m) nice-all-RT-tasks(n) poweroff(o) show-registers(p) show-all-timers(q) unraw(r) sync(s) show-task-states(t) unmount(u) force-fb(V) show-blocked-tasks(w) dump-ftrace-buffer(z)
- Alt+SysRq+m
дек 10 13:09:09 arch kernel: sysrq: Show Memory
дек 10 13:09:09 arch kernel: Mem-Info:
..... и так далее ...
Найти в журнале легко - по сочетанию arch kernel: sysrq:
Потренируйся, чтобы потом мог легко нажимать и делать поиск в логах.

EDIT 1- нужно понять - отразится ли это в логах ... можно запустить терминал и в нем команду journalctl -f , чтобы потом, при зависании и после нажатия нужных комбинаций, узнать видны ли будут выводы. Если логов не будет, значит потребуется что то другое.

EDIT 2 - и да, маловероятно, что зависание происходит само по себе - а потому должен четко запоминать какие приложения запускал перед этим.
Ошибки не исчезают с опытом - они просто умнеют
vasek,
спасибо за инструкцию, всё это сохранил себе, но в принипе я так и делал
Далее, нужно точно знать работает ли эта комбинация при зависании и исходя из этого сделать заключение
ну вот никакая из комбинаций и не работала, логи чисты.

Сейчас посмотрю железные потроха на наличие проблем, потом в биосе покопаюсь. Машине уже лет эдак 8.
vasek
и да, маловероятно, что зависание происходит само по себе - а потому должен четко запоминать какие приложения запускал перед этим
Как раз это чаще всего и бывает ;)
У меня старый ноут на ядре 5.9 стал подвисать с морганием лампочки капслока. Когда в простое не виснет, а под нагрузкой виснет, но предсказать когда невозможно.
На 5.8 работает без проблем.
такие дела.
 
Зарегистрироваться или войдите чтобы оставить сообщение.