Анализ и отладка упавшей/сбойной системы

vasek	# 7 лет, 9 месяцев назад (отредактировано 2 года, 6 месяцев назад)
Темы: 47 Сообщения: 11853 Участник с: 17 февраля 2013	Смотрю новички теряются, когда у них падает система — не могут даже посмотреть логи, откатиться и др. Написано наспех ..... возможны и ошибки ...... прошу строго не судить ... Чтобы ориентироваться в причинах сбоя/падения системы, желательно знать на каком этапе загрузки произошел сбой — это, можно сказать, половина успеха. А потому необходимо знать этапы начальной загрузки системы, которые хорошо описаны и разбирать их не будем. Простейшую схему загрузки (без UEFI) можно представить так BIOS — MBR — GRUB — KERNEL — INIT Подробно описывать не буду (все можно найти в интернете), но кратко опишу последний этап загрузки - загрузчик загружает в память образ ядра, которое инициализирует и подготавливает память, оборудование , монтирует корневой раздел для загрузки остальной системы. И если все нормально и ошибок нет, то после инициализации ядро передает управление процеcсу init (первому системному процессу с PID=1). В качестве процесса init Archlinux использует systemd. Как правило, в большинстве случаев, сбой/падение системы наблюдается после процесса монтирования корневого раздела для загрузки системы и передачи управления процессу init. А следовательно, для просмотра логов, отладки и действий по дальнейшему восстановлению системы в этом случае удобнее воспользоваться средствами systemd, а именно emergency.target и debug-shell.service. Конечно, debug-shell.service не панацея от всех бед и, следует помнить, что его возможности успешны если затык произошел в процессе загрузки systemd …. и чем дальше продвинулась загрузка systemd, тем лучше. И, главное, не нужен сhroot …. Но, не сомненно, есть ситуации когда без chroot (или live CD) никуда. Но я обычно всегда в 1-ую очередь пытаюсь пробовать emergency.target и debug-shell.service. Чтобы примерно определиться на каком этапе произошел сбой/падение (если это не ясно из сообщений о падении системы), можно загрузиться в режим emergency - аварийный режим - аналог (но не полный) однопользовательского режима (single user mode) - базовая система сконфигурирована, но демоны не запущены (останов после передачи управления процессу init - сразу после приветствия Arch Linux). Если загрузились успешно и нам предлагают ввести пароль root, то мы перед падением, что облегчает дальнейший анализ. Если загрузка неуспешная, разумно предположить, что наиболее вероятными причинами могут быть проблемы с загрузчиком, ядром, иницилизацией оборудования, монтированием корневого раздела. Это можно также проверить загрузившись с параметром break или break=premount и если загрузка до конца не состоится, то это означает, что падение произошло до монтирования файловой системы ….. Во всех этих случаях конкретное место падения можно также определить по сообщениям на экране монитора и для этого целесообразно увеличить информационность логирования, например, загрузившись с параметром debug (некоторые советуют добавить дополнительно и параметр ignore_loglevel). Но проведение анализа и устранение причин в этих случаях средствами systemd не возможно. Восстановление системы в тяжелых случаях падения, когда применение emergency mode и debug-shell.service бесполезно, лучше проводить средствами chroot - Wiki Загрузка в режим emergency Прописываем в меню grub параметр загрузки emergency и F10 для продолжения загрузи. Чтобы попасть в меню grub нажимаем «e» на выбранной системе. После останова загрузки в данном режиме и ввода пароля root можно - смотреть логи, например, для просмотра лога предыдущей сбойной загрузки journalctl -b -1 - выполнить откат к старому пакету (если старый пакет находится здесь же) - другие операции, выполняемые с pacman - что то записать - и др. Удобно работать с mc, но один большой минус — не отображается кирилица. EDIT - уточнение. В Linux есть такое понятие - Recovery shells - получение интерактивной оболочки на этапе процесса загрузки, что можно использовать для решения определенных проблем с системой - грубо говоря, можно остановить загрузку на определенном этапе, определяемом выбором Recovery shells, выполнить соответствующие действия и продолжить загрузку. Существует 3 типа Recovery shells (названия используются в качестве параметров загрузки) rescue (другое название single) - режим восстановления - в котором все локальные файловые системы будут примонтированы, но только некоторые важные службы будут запущены. emergency - аварийный режим - в котором файловые системы еще не смонтированы, службы и сокеты не запущены. Из режима emergency можно продолжить загрузку с остановом в режиме rescue используя команду systemctl rescue. init=/bin/sh - в этом режиме загрузка осуществляется прямо в оболочку (shell), что позволяет использовать это в случае, когда не получается загрузиться в аварийном режиме, например, в случае испорченных библиотек systemd, повреждения файловой системы. Но чтобы предпринять более существенные действия по восстановлению системы, возможному подключению интернета и другим действиям, желательно активировать debug-shell.service. Для чего выполняем следующие действия `mount -o remount,rw / …..# сейчас запускается в режиме rw (но лучше выполнить) cd /etc/systemd/system mkdir -p sysinit.target.wants ln -s /usr/lib/systemd/system/debug-shell.service sysinit.target.wants/` и перегружаемся..... Загрузка debug-shell.service Прописываем в меню grub systemd.log_level=debug systemd.log_target=kmsg log_buf_len=1M F10 и после, как увидим приглашение - Welcome to Arch Linux .... , переходим в текстовую консоль F9 (Ctrl+Alt+F9) ....и попадаем в root shell . Смотрим загрузку и где затык....можно посмотреть зависшие процессы systemctl list-jobs, поработать с pacman, проверить возможность подключения к интернет (я это делаю через 3G modem), выполнить обновления и многое другое. UPD....после окончания работы с debug-shell.service не забываем выполнить systemctl disable debug-shell.service ...... в целях безопасности.... Можно, конечно, активировать debug-shell.service на постоянку (systemctl enable debug-shell.service) и тогда не нужно будет активировать его из emergency mode........ но это на любителя и не забывайте, что этот сервис дает полный доступ к системе. Дополнение в части debug-shell.service - появился новый параметр ядра, очень удобный - позволяет активировать debug-shell.service только на текущую загрузку (режим runtime), а не на постоянку ... то есть юнит не прописывается в /etc/systemd/system. ... Для активации нужно в момент загрузки в меню Grub нажать e на загружаемой системе и дописать параметр ядра systemd.debug-shell=1 а для увеличения логирования можно дописать systemd.log_level=debug .... и нажать F10 Далее в процессе загрузки или после остановки переключится в консоль debug-shell - Alt+Ctrl+F9 UPD ….. Проверка файловой системы fsck - Wiki Проверку можно выполнить, загрузившись с параметром загрузки break или break=premount (останов загрузки до монтирования файловой системы) ~~и по рекомендации Wiki «To automatically repair damaged portions, run: fsck -a »~~ ... лучше по старинке с опцией -f PS ... Забыл дать ссылку на нашу Wiki - General troubleshooting (Устранение общих неполадок в системе) — возможно пригодится ... лучше читать en Проблемы с выключением 1. Долгое выключение — получаем лог shutdown и анализуруем его (смотрим тайм-ауты и др.). Для получения лога - создаем скрипт /usr/lib/systemd/system-shutdown/debug.sh (не забыть сделать его исполняемым): `#!/bin/sh mount -o remount,rw / dmesg > /shutdown-log.txt mount -o remount,ro /` - перегружаемся со следующими параметрами: systemd.log_level=debug systemd.log_target=kmsg log_buf_len=1M printk.devkmsg=on - выключаем ….... включаем и анализируем файл /shutdown-log.txt Начало завершения/выключения — ищем строку типа systemd[1]: Stopping Session 1 of user …такой-то..... (в начале будет идти дата и время, если что тормозит, смотрим на время) ........ 2. Не выключается Если реагирует на клавиатуру и дает попасть в другую консоль, пробуем принудительно перегрузить/выключить командами # sync && reboot -f # sync && poweroff -f Если на клавиатуру не реагирует, пробуем принудительно перегрузить/выключить используя волшебные кнопки - R E I S U B / R E I S U O (при этом sysrq должен быть равен 1) Если ни одна из команд не работает, то это ошибка ядра - если работают, то это ошибка systemd или железа. Для чтения логов в этом случае необходимо применять другие способы (последовательная консоль, ssh и т. п.), чего как правило, у большинства нет. Но можно попробовать использовать debug-shell.service ….... - # systemctl enable debug-shell.service - перегружаемся со следующими параметрами: systemd.log_level=debug systemd.log_target=kmsg log_buf_len=1M (…. log_buf_len=1M ….... не обязателен) - shutdown ….. и идем в tty9, запускам dmesg и смотрим …. + ps aux и смотрим не завершенные процессы …. + можно и systemctl list-jobs ... и в конце poweroff --force и смотрим его работу … ДОПОЛНЕНИЕ - иногда возникают и ситуации, что система не упала, работоспособна, но имеют случаи отдельные зависания системы … или имеются проблемы с работой отделных сервисов systemd … или можно спокойно загрузиться в текстовую консоль, а вот при загрузке X-ов возникают проблемы и другое. Не стал описывать здесь, а вынес в отдельные блоги следующие две темы Анализ зависшего процесса - описаны способы определения зависшего процесса, статья чисто ознакомительная, чтобы не теряться, а хотя бы иметь представление, что можно предпринять для простого анализа возникшей проблемы. Способы нестандартной отладки/трассировки Х-ов, unit-ов systemd, udev, модулей - описаны способы получения дополнительной информации при решении проблем с Xorg, сервисов systemd, модулей, в случаях когда стандартных логов, например, journal не достаточно. ДОПОЛНЕНИЕ в части логирования initramfs Иногда, правда редко, дело до загрузки systemd не доходит, система падает при загрузке initramfs - и в этом случае могут помочь следующие параметры командной строки ядра, наличие которых позволит получить логи initramfs - польза, конечно, не большая, но, как говоротся, на без рыбье и рак рыба ... rd.log=console\|file\|kmsg\|all - включает запись ранних сообщений в пространстве пользователя. Имеет 4 параметра: console, file, kmsg, all - несколько опций можно объединить с помощью символа «\|». Сообщения всегда записываются на консоль, если не передан параметр quiet. Если параметр не указан, предполагается kmsg \| console. Если rd.log отсутствует в командной строке ядра, регистрация не производится. console - записывает вывод в консоле (/dev/console) file - записывает вывод в файл /run/initramfs/init.log kmsg - записывает вывод в лог kmsg (/dev/kmsg device) all - записывает вывод в во все перечисленные цели rd.debug - включает отладку оболочки (xtrace). Если rd.log не пррописан, то подразумевается rd.log=console Нюанс в части сохранения логов а файл - файл хранится только в текущей загрузке, при не удачной загрузке и перегрузке файла уже не будет. В этом случае придется смотреть лог в консоле, лучше прописывать rd.debug rd.log=all ДОПОЛНЕНИЕ в части логирования grub Лог еще нигде не пишется, но посмотреть его можно ... одно но, бежит он очень быстро, можно что то прочитать, если будет останов/задержка. Для этого нужно прописать в grub.cfg две строчки `set pager=1 set debug=all` параметр set pager=1 нужен для того, чтобы быстро не бежало и можно было листать логи в консоле. ДОПОЛНЕНИЕ в части ступенчатой загрузки Иногда для выявления/уточнения места затыка удобно использовать ступенчатую загрузку: emergency mode — rescue mode — default mode - сначала грузимся в emergency mode - если все нормально и увидели «Welcome to ArchLinux!» и предложение ввести пароль root, то вводи пароль … и грузимся дальше в в rescue mode, для чего вводим команду systemctl rescue и если все нормально и предложили ввести пароль root, то в вводим снова пароль root (при необходимости смотри/делаем что необходимо, уточнение - если установлен и активирован DM, то в этих режимах он пока еще не задействован). Если опять все нормально, грузимся дальше в default mode (обычный режим работы по дефолту), для чего вводим команду systemctl defaut (вот если DM активирован, то он на этом этапе и сработает). ДОПОЛНЕНИЕ в части анализа нагрузки cpu, памяти и др. Иногда полезно помониторить нагрузку cpu, памяти и др. в динамике, за определенный промежуток времени. Хорошо подходит для этих целей утилита atop. Лучшей утилиты для анализа затыка в системе вряд ли найдется - есть, конечно, еще один профессиональный комбайн, но для нас, обычных юзеров, все-таки atop намного проще. Несомненно, не имею ничего протов утилит типа top, htop, bpytop и др., но это все утилиты типа посмотреть, что там сейчас твориться в системе. Но сидеть и тупо смотреть в монитор, отлавливая виновника проблем не очень то и хороший способ. Проще всего запустить atop и ни о чем не думая продолжить работу на компьютере - atop запишет в бинарный файл с указанной Вами периодичностью все параметры системы и будет хранить их столько время, сколько Вы ему укажите. Выбрав свободное время можете заняться анализом - смотреть логи, точнее тот же вывод atop, но последовательно, как развивались события, одним нажатием клавиши, просто как листая журнал - и можете увидеть как менялись параметры системы по времени. Но можно посмотреть и проще - например, посмотреть за определенный промежуток времени как менялись значения ОЗУ, например, 15.12.2020 с 17:10:00 до 18:00:00 atopsar -r /var/log/atop/atop_20201215 -m -b 17:10:00 -e 18:00:00 `-------------------------- analysis date: 2020/12/15 -------------------------- 17:11:54 memtotal memfree buffers cached dirty slabmem swptotal swpfree _mem_ 17:21:54 5875M 3802M 240M 818M 0M 320M 0M 0M 17:31:54 5875M 3806M 241M 817M 0M 320M 0M 0M 17:41:54 5875M 137M 269M 771M 0M 227M 0M 0M 17:51:54 5875M 3978M 242M 804M 0M 227M 0M 0M 17:55:33 5875M 4074M 243M 740M 0M 227M 0M 0M` И что там за приложение так много потребляло памяти? - выведем тройку жрущих процессов за тот же период времени atopsar -r /var/log/atop/atop_20201215 -G -b 17:10:00 -e 18:00:00 `-------------------------- analysis date: 2020/12/15 -------------------------- 17:11:54 pid command mem% \| pid command mem% \| pid command mem%_top3_ 17:21:54 802 palemoon 11% \| 472 tilix 1% \| 457 Xorg 1% 17:31:54 802 palemoon 11% \| 472 tilix 1% \| 457 Xorg 1% 17:41:54 98846 mirage 22% \| 99092 mirage 22% \| 98808 mirage 12% 17:51:54 802 palemoon 8% \| 99894 soffice. 3% \| 457 Xorg 2% 17:55:33 802 palemoon 9% \| 472 tilix 1% \| 457 Xorg 1%` Ну вот, обжорством занимался mirage - как минимум было открыто 3 приложения, который забрали более половины памяти. PS - Интерсно и то, что памяти практически не осталось, но система не висла - отработал earlyoom, установленный у меня. Также можно посмотреть и нагрузку cpu за тот же период (тройку наиболее жрущих) atopsar -r /var/log/atop/atop_20201215 -O -b 17:10:00 -e 18:00:00 `-------------------------- analysis date: 2020/12/15 -------------------------- 17:11:54 pid command cpu% \| pid command cpu% \| pid command cpu%_top3_ 17:21:54 802 palemoon 10% \| 457 Xorg 3% \| 472 tilix 1% 17:31:54 472 tilix 3% \| 457 Xorg 2% \| 802 palemoon 2% 17:41:54 472 tilix 3% \| 97828 gmain 2% \| 457 Xorg 2% 17:51:54 457 Xorg 3% \| 99894 soffice. 3% \| 472 tilix 2% 17:55:33 802 palemoon 6% \| 99894 pool-sof 5% \| 457 Xorg 3%` Как видим нагрузка cpu особо и не менялась. Можно эти команды и не писать, а просто выбрать нужный день и запустить atop, типа atop -r /var/log/atop/atop_20201215 и смотреть экран atop в динамике - просто листая, как книгу: t - вперед, t + Shift - назад (будет вывод похожий на top, но в разные моменты времени) PS - для обладателей nvidia - можно смотреть GPU statistics (но нужно установить один модуль) - что это такое, не пробовал ДОПОЛНЕНИЕ в части анализа проблем с DRM (Direct Rendering Manager) - проблем при загрузке Х-ов ... и не только при загрузке ... Если Вы столкнулись при загрузке Х-ов с некоторыми проблемами графики, дисплеем и др., то можно увеличить логирование драйвера DRM, что может помочь понять причину проблем. Включение отладочных сообщений выполняется с помощью параметра drm.debug с активированием соотвествующего бита: `drm.debug=0x1 will enable CORE messages drm.debug=0x2 will enable DRIVER messages drm.debug=0x3 will enable CORE and DRIVER messages … drm.debug=0x1ff will enable all messages` Рекомендую начать с параметра drm.debug=0xe или, если имеются проблемы с отображением, использовать drm.debug=0x1e При этом следует прописывать два параметра, например `drm.debug=0x1e log_buf_len=8M` PS - значение параметра drm.debug прописано в /sys/module/drm/parameters/debug, то есть его можно и посмотреть и даже изменить в загруженной системе (то есть можно настроить логирование без выполнения reboot, если проблемы возникают в процессе работы) Забыл отметить - отладочные сообщения будут прописаны в journal ... смотрим journalctl <соответствующий параметр> Ошибки не исчезают с опытом - они просто умнеют

# 7 лет, 9 месяцев назад (отредактировано 2 года, 6 месяцев назад)

Сообщения: 11853

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

Смотрю новички теряются, когда у них падает система — не могут даже посмотреть логи, откатиться и др.
Написано наспех ..... возможны и ошибки ...... прошу строго не судить ...
Чтобы ориентироваться в причинах сбоя/падения системы, желательно знать на каком этапе загрузки произошел сбой — это, можно сказать, половина успеха. А потому необходимо знать этапы начальной загрузки системы, которые хорошо описаны и разбирать их не будем.
Простейшую схему загрузки (без UEFI) можно представить так
BIOS — MBR — GRUB — KERNEL — INIT
Подробно описывать не буду (все можно найти в интернете), но кратко опишу последний этап загрузки - загрузчик загружает в память образ ядра, которое инициализирует и подготавливает память, оборудование , монтирует корневой раздел для загрузки остальной системы. И если все нормально и ошибок нет, то после инициализации ядро передает управление процеcсу init (первому системному процессу с PID=1). В качестве процесса init Archlinux использует systemd.
Как правило, в большинстве случаев, сбой/падение системы наблюдается после процесса монтирования корневого раздела для загрузки системы и передачи управления процессу init. А следовательно, для просмотра логов, отладки и действий по дальнейшему восстановлению системы в этом случае удобнее воспользоваться средствами systemd, а именно emergency.target и debug-shell.service.
Конечно, debug-shell.service не панацея от всех бед и, следует помнить, что его возможности успешны если затык произошел в процессе загрузки systemd …. и чем дальше продвинулась загрузка systemd, тем лучше. И, главное, не нужен сhroot …. Но, не сомненно, есть ситуации когда без chroot (или live CD) никуда. Но я обычно всегда в 1-ую очередь пытаюсь пробовать emergency.target и debug-shell.service.
Чтобы примерно определиться на каком этапе произошел сбой/падение (если это не ясно из сообщений о падении системы), можно загрузиться в режим emergency - аварийный режим - аналог (но не полный) однопользовательского режима (single user mode) - базовая система сконфигурирована, но демоны не запущены (останов после передачи управления процессу init - сразу после приветствия Arch Linux). Если загрузились успешно и нам предлагают ввести пароль root, то мы перед падением, что облегчает дальнейший анализ.
Если загрузка неуспешная, разумно предположить, что наиболее вероятными причинами могут быть проблемы с загрузчиком, ядром, иницилизацией оборудования, монтированием корневого раздела. Это можно также проверить загрузившись с параметром break или break=premount и если загрузка до конца не состоится, то это означает, что падение произошло до монтирования файловой системы …..
Во всех этих случаях конкретное место падения можно также определить по сообщениям на экране монитора и для этого целесообразно увеличить информационность логирования, например, загрузившись с параметром debug (некоторые советуют добавить дополнительно и параметр ignore_loglevel).
Но проведение анализа и устранение причин в этих случаях средствами systemd не возможно. Восстановление системы в тяжелых случаях падения, когда применение emergency mode и debug-shell.service бесполезно, лучше проводить средствами chroot - Wiki

Загрузка в режим emergency
Прописываем в меню grub параметр загрузки emergency и F10 для продолжения загрузи. Чтобы попасть в меню grub нажимаем «e» на выбранной системе.
После останова загрузки в данном режиме и ввода пароля root можно
- смотреть логи, например, для просмотра лога предыдущей сбойной загрузки journalctl -b -1
- выполнить откат к старому пакету (если старый пакет находится здесь же)
- другие операции, выполняемые с pacman
- что то записать
- и др.
Удобно работать с mc, но один большой минус — не отображается кирилица.

EDIT - уточнение. В Linux есть такое понятие - Recovery shells - получение интерактивной оболочки на этапе процесса загрузки, что можно использовать для решения определенных проблем с системой - грубо говоря, можно остановить загрузку на определенном этапе, определяемом выбором Recovery shells, выполнить соответствующие действия и продолжить загрузку.
Существует 3 типа Recovery shells (названия используются в качестве параметров загрузки)
rescue (другое название single) - режим восстановления - в котором все локальные файловые системы будут примонтированы, но только некоторые важные службы будут запущены.
emergency - аварийный режим - в котором файловые системы еще не смонтированы, службы и сокеты не запущены. Из режима emergency можно продолжить загрузку с остановом в режиме rescue используя команду systemctl rescue.
init=/bin/sh - в этом режиме загрузка осуществляется прямо в оболочку (shell), что позволяет использовать это в случае, когда не получается загрузиться в аварийном режиме, например, в случае испорченных библиотек systemd, повреждения файловой системы.

Но чтобы предпринять более существенные действия по восстановлению системы, возможному подключению интернета и другим действиям, желательно активировать debug-shell.service. Для чего выполняем следующие действия

mount -o remount,rw / …..# сейчас запускается в режиме rw (но лучше выполнить)
cd /etc/systemd/system
mkdir -p sysinit.target.wants
ln -s /usr/lib/systemd/system/debug-shell.service sysinit.target.wants/

и перегружаемся.....
Загрузка debug-shell.service
Прописываем в меню grub
systemd.log_level=debug systemd.log_target=kmsg log_buf_len=1M
F10 и после, как увидим приглашение - Welcome to Arch Linux .... , переходим в текстовую консоль F9 (Ctrl+Alt+F9) ....и попадаем в root shell .
Смотрим загрузку и где затык....можно посмотреть зависшие процессы systemctl list-jobs, поработать с pacman, проверить возможность подключения к интернет (я это делаю через 3G modem), выполнить обновления и многое другое.
UPD....после окончания работы с debug-shell.service не забываем выполнить
systemctl disable debug-shell.service ...... в целях безопасности....
Можно, конечно, активировать debug-shell.service на постоянку (systemctl enable debug-shell.service) и тогда не нужно будет активировать его из emergency mode........ но это на любителя и не забывайте, что этот сервис дает полный доступ к системе.

Дополнение в части debug-shell.service - появился новый параметр ядра, очень удобный - позволяет активировать debug-shell.service только на текущую загрузку (режим runtime), а не на постоянку ... то есть юнит не прописывается в /etc/systemd/system. ... Для активации нужно в момент загрузки в меню Grub нажать e на загружаемой системе и дописать параметр ядра systemd.debug-shell=1 а для увеличения логирования можно дописать systemd.log_level=debug .... и нажать F10
Далее в процессе загрузки или после остановки переключится в консоль debug-shell - Alt+Ctrl+F9

UPD …..
Проверка файловой системы fsck - Wiki
Проверку можно выполнить, загрузившись с параметром загрузки break или break=premount (останов загрузки до монтирования файловой системы) ~~и по рекомендации Wiki «To automatically repair damaged portions, run: fsck -a »~~ ... лучше по старинке с опцией -f

PS ... Забыл дать ссылку на нашу Wiki - General troubleshooting (Устранение общих неполадок в системе) — возможно пригодится ... лучше читать en

Проблемы с выключением

1. Долгое выключение — получаем лог shutdown и анализуруем его (смотрим тайм-ауты и др.). Для получения лога
- создаем скрипт /usr/lib/systemd/system-shutdown/debug.sh (не забыть сделать его исполняемым):

#!/bin/sh
mount -o remount,rw /
dmesg > /shutdown-log.txt
mount -o remount,ro /

- перегружаемся со следующими параметрами:
systemd.log_level=debug systemd.log_target=kmsg log_buf_len=1M printk.devkmsg=on
- выключаем ….... включаем и анализируем файл /shutdown-log.txt
Начало завершения/выключения — ищем строку типа systemd[1]: Stopping Session 1 of user …такой-то.....
(в начале будет идти дата и время, если что тормозит, смотрим на время) ........

2. Не выключается
Если реагирует на клавиатуру и дает попасть в другую консоль, пробуем принудительно перегрузить/выключить командами
# sync && reboot -f
# sync && poweroff -f
Если на клавиатуру не реагирует, пробуем принудительно перегрузить/выключить используя волшебные кнопки -
R E I S U B / R E I S U O (при этом sysrq должен быть равен 1)
Если ни одна из команд не работает, то это ошибка ядра - если работают, то это ошибка systemd или железа.
Для чтения логов в этом случае необходимо применять другие способы (последовательная консоль, ssh и т. п.), чего как правило, у большинства нет.
Но можно попробовать использовать debug-shell.service …....
- # systemctl enable debug-shell.service
- перегружаемся со следующими параметрами:
systemd.log_level=debug systemd.log_target=kmsg log_buf_len=1M
(…. log_buf_len=1M ….... не обязателен)
- shutdown ….. и идем в tty9, запускам dmesg и смотрим …. + ps aux и смотрим не завершенные процессы …. + можно и systemctl list-jobs ... и в конце poweroff --force и смотрим его работу …

ДОПОЛНЕНИЕ - иногда возникают и ситуации, что система не упала, работоспособна, но имеют случаи отдельные зависания системы … или имеются проблемы с работой отделных сервисов systemd … или можно спокойно загрузиться в текстовую консоль, а вот при загрузке X-ов возникают проблемы и другое. Не стал описывать здесь, а вынес в отдельные блоги следующие две темы

Анализ зависшего процесса - описаны способы определения зависшего процесса, статья чисто ознакомительная, чтобы не теряться, а хотя бы иметь представление, что можно предпринять для простого анализа возникшей проблемы.

Способы нестандартной отладки/трассировки Х-ов, unit-ов systemd, udev, модулей - описаны способы получения дополнительной информации при решении проблем с Xorg, сервисов systemd, модулей, в случаях когда стандартных логов, например, journal не достаточно.

ДОПОЛНЕНИЕ в части логирования initramfs
Иногда, правда редко, дело до загрузки systemd не доходит, система падает при загрузке initramfs - и в этом случае могут помочь следующие параметры командной строки ядра, наличие которых позволит получить логи initramfs - польза, конечно, не большая, но, как говоротся, на без рыбье и рак рыба ...
rd.log=console|file|kmsg|all - включает запись ранних сообщений в пространстве пользователя. Имеет 4 параметра: console, file, kmsg, all - несколько опций можно объединить с помощью символа «|». Сообщения всегда записываются на консоль, если не передан параметр quiet. Если параметр не указан, предполагается kmsg | console. Если rd.log отсутствует в командной строке ядра, регистрация не производится.
console - записывает вывод в консоле (/dev/console)
file - записывает вывод в файл /run/initramfs/init.log
kmsg - записывает вывод в лог kmsg (/dev/kmsg device)
all - записывает вывод в во все перечисленные цели

rd.debug - включает отладку оболочки (xtrace). Если rd.log не пррописан, то подразумевается rd.log=console

Нюанс в части сохранения логов а файл - файл хранится только в текущей загрузке, при не удачной загрузке и перегрузке файла уже не будет. В этом случае придется смотреть лог в консоле, лучше прописывать rd.debug rd.log=all

ДОПОЛНЕНИЕ в части логирования grub
Лог еще нигде не пишется, но посмотреть его можно ... одно но, бежит он очень быстро, можно что то прочитать, если будет останов/задержка. Для этого нужно прописать в grub.cfg две строчки

set pager=1
set debug=all

параметр set pager=1 нужен для того, чтобы быстро не бежало и можно было листать логи в консоле.

ДОПОЛНЕНИЕ в части ступенчатой загрузки
Иногда для выявления/уточнения места затыка удобно использовать ступенчатую загрузку: emergency mode — rescue mode — default mode
- сначала грузимся в emergency mode - если все нормально и увидели «Welcome to ArchLinux!» и предложение ввести пароль root, то вводи пароль … и грузимся дальше в в rescue mode, для чего вводим команду systemctl rescue и если все нормально и предложили ввести пароль root, то в вводим снова пароль root (при необходимости смотри/делаем что необходимо, уточнение - если установлен и активирован DM, то в этих режимах он пока еще не задействован). Если опять все нормально, грузимся дальше в default mode (обычный режим работы по дефолту), для чего вводим команду systemctl defaut (вот если DM активирован, то он на этом этапе и сработает).

ДОПОЛНЕНИЕ в части анализа нагрузки cpu, памяти и др.
Иногда полезно помониторить нагрузку cpu, памяти и др. в динамике, за определенный промежуток времени. Хорошо подходит для этих целей утилита atop. Лучшей утилиты для анализа затыка в системе вряд ли найдется - есть, конечно, еще один профессиональный комбайн, но для нас, обычных юзеров, все-таки atop намного проще.
Несомненно, не имею ничего протов утилит типа top, htop, bpytop и др., но это все утилиты типа посмотреть, что там сейчас твориться в системе. Но сидеть и тупо смотреть в монитор, отлавливая виновника проблем не очень то и хороший способ. Проще всего запустить atop и ни о чем не думая продолжить работу на компьютере - atop запишет в бинарный файл с указанной Вами периодичностью все параметры системы и будет хранить их столько время, сколько Вы ему укажите.
Выбрав свободное время можете заняться анализом - смотреть логи, точнее тот же вывод atop, но последовательно, как развивались события, одним нажатием клавиши, просто как листая журнал - и можете увидеть как менялись параметры системы по времени.
Но можно посмотреть и проще - например, посмотреть за определенный промежуток времени как менялись значения ОЗУ, например, 15.12.2020 с 17:10:00 до 18:00:00
atopsar -r /var/log/atop/atop_20201215 -m -b 17:10:00 -e 18:00:00

-------------------------- analysis date: 2020/12/15 --------------------------

17:11:54  memtotal memfree buffers cached dirty slabmem  swptotal swpfree _mem_
17:21:54     5875M   3802M    240M   818M    0M    320M        0M      0M
17:31:54     5875M   3806M    241M   817M    0M    320M        0M      0M
17:41:54     5875M    137M    269M   771M    0M    227M        0M      0M
17:51:54     5875M   3978M    242M   804M    0M    227M        0M      0M
17:55:33     5875M   4074M    243M   740M    0M    227M        0M      0M

И что там за приложение так много потребляло памяти? - выведем тройку жрущих процессов за тот же период времени
atopsar -r /var/log/atop/atop_20201215 -G -b 17:10:00 -e 18:00:00

-------------------------- analysis date: 2020/12/15 --------------------------

17:11:54    pid command  mem% |   pid command  mem% |   pid     command   mem%_top3_
17:21:54    802 palemoon  11%    |   472 tilix                1% |   457        Xorg             1%
17:31:54    802 palemoon  11%    |   472 tilix                1% |   457        Xorg             1%
17:41:54  98846 mirage    22%    | 99092 mirage        22% | 98808     mirage          12%
17:51:54    802 palemoon   8%    | 99894 soffice.          3% |   457        Xorg             2%
17:55:33    802 palemoon   9%    |   472 tilix                 1% |   457         Xorg            1%

Ну вот, обжорством занимался mirage - как минимум было открыто 3 приложения, который забрали более половины памяти.
PS - Интерсно и то, что памяти практически не осталось, но система не висла - отработал earlyoom, установленный у меня.

Также можно посмотреть и нагрузку cpu за тот же период (тройку наиболее жрущих)
atopsar -r /var/log/atop/atop_20201215 -O -b 17:10:00 -e 18:00:00

-------------------------- analysis date: 2020/12/15 --------------------------

17:11:54    pid  command  cpu% |   pid   command  cpu% |   pid   command  cpu%_top3_
17:21:54    802 palemoon   10% |   457      Xorg          3% |   472      tilix              1%
17:31:54    472 tilix              3% |   457      Xorg          2% |   802     palemoon      2%
17:41:54    472 tilix              3% | 97828    gmain        2% |   457       Xorg            2%
17:51:54    457 Xorg            3% | 99894    soffice.      3% |   472        tilix             2%
17:55:33    802 palemoon     6% | 99894   pool-sof     5% |   457       Xorg            3%

Как видим нагрузка cpu особо и не менялась.
Можно эти команды и не писать, а просто выбрать нужный день и запустить atop, типа atop -r /var/log/atop/atop_20201215 и смотреть экран atop в динамике - просто листая, как книгу: t - вперед, t + Shift - назад (будет вывод похожий на top, но в разные моменты времени)

PS - для обладателей nvidia - можно смотреть GPU statistics (но нужно установить один модуль) - что это такое, не пробовал

ДОПОЛНЕНИЕ в части анализа проблем с DRM (Direct Rendering Manager) - проблем при загрузке Х-ов ... и не только при загрузке ...
Если Вы столкнулись при загрузке Х-ов с некоторыми проблемами графики, дисплеем и др., то можно увеличить логирование драйвера DRM, что может помочь понять причину проблем.
Включение отладочных сообщений выполняется с помощью параметра drm.debug с активированием соотвествующего бита:

drm.debug=0x1 will enable CORE messages
drm.debug=0x2 will enable DRIVER messages
drm.debug=0x3 will enable CORE and DRIVER messages
…
drm.debug=0x1ff will enable all messages

Рекомендую начать с параметра drm.debug=0xe или, если имеются проблемы с отображением, использовать drm.debug=0x1e
При этом следует прописывать два параметра, например

drm.debug=0x1e  log_buf_len=8M

PS - значение параметра drm.debug прописано в /sys/module/drm/parameters/debug, то есть его можно и посмотреть и даже изменить в загруженной системе (то есть можно настроить логирование без выполнения reboot, если проблемы возникают в процессе работы)
Забыл отметить - отладочные сообщения будут прописаны в journal ... смотрим journalctl <соответствующий параметр>

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

R.V.	# 7 лет, 9 месяцев назад
Темы: 11 Сообщения: 1100 Участник с: 10 января 2017	Очень даже полезная тема! +1

vasek	# 7 лет, 9 месяцев назад (отредактировано 7 лет, 9 месяцев назад)
Темы: 47 Сообщения: 11853 Участник с: 17 февраля 2013	Насчет о возможности отката пакетов ..... лучше даю ссылку из одного топика по обсуждению упавшей системы lo7ev Зашел через emergency откатил linux, linux-headers, acpi_call, systems. Все починилоь Ошибки не исчезают с опытом - они просто умнеют

vasek

# 7 лет, 9 месяцев назад (отредактировано 7 лет, 9 месяцев назад)

Темы: 47

Сообщения: 11853

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

Насчет о возможности отката пакетов ..... лучше даю ссылку из одного топика по обсуждению упавшей системы

lo7ev
Зашел через emergency откатил linux, linux-headers, acpi_call, systems. Все починилоь

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

Romshot	# 7 лет, 9 месяцев назад
Темы: 1 Сообщения: 50 Участник с: 06 октября 2016	ИМХО, но здесь немного не место, где подобную инструкцию можно разместить. Может запилить совместными усилиями на вики? Во всяком случае, там можно будет алгоритм хорошо структурировать, а еще, после хорошего допила и на главной разместить, поскольку очень полезная идея.

Romshot

# 7 лет, 9 месяцев назад

Темы: 1

Сообщения: 50

Участник с: 06 октября 2016

ИМХО, но здесь немного не место, где подобную инструкцию можно разместить. Может запилить совместными усилиями на вики? Во всяком случае, там можно будет алгоритм хорошо структурировать, а еще, после хорошего допила и на главной разместить, поскольку очень полезная идея.

ZeniaM	# 7 лет, 9 месяцев назад
Темы: 37 Сообщения: 298 Участник с: 20 сентября 2015	vasek спасибо!

vasek	# 7 лет, 9 месяцев назад
Темы: 47 Сообщения: 11853 Участник с: 17 февраля 2013	Romshot ИМХО, но здесь немного не место, где подобную инструкцию можно разместить. Может запилить совместными усилиями на вики? Во всяком случае, там можно будет алгоритм хорошо структурировать, а еще, после хорошего допила и на главной разместить, поскольку очень полезная идея. В принципе это не инструкция, просто приведены основные положения/направления ....... чтобы можно было от чего то оттолкнуться .... всего не опишешь, все варианты не предусмотришь … и предстоит дополнительное и гугление и анализ ... Имеется много чего по отладке, но все это раскидано. Думал постепенно дополнять ... Но гложет мысль, что все это лишнее - система уже практически и не падает (сам уже года 2 как вообще перестал делать backup системы, только важной документации) .... а у новичков больше проблем по отладке приложений, а это уже совсем другое ... Ошибки не исчезают с опытом - они просто умнеют

vasek

# 7 лет, 9 месяцев назад

Темы: 47

Сообщения: 11853

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

Romshot
ИМХО, но здесь немного не место, где подобную инструкцию можно разместить. Может запилить совместными усилиями на вики? Во всяком случае, там можно будет алгоритм хорошо структурировать, а еще, после хорошего допила и на главной разместить, поскольку очень полезная идея.

В принципе это не инструкция, просто приведены основные положения/направления ....... чтобы можно было от чего то оттолкнуться .... всего не опишешь, все варианты не предусмотришь … и предстоит дополнительное и гугление и анализ ...
Имеется много чего по отладке, но все это раскидано. Думал постепенно дополнять ...
Но гложет мысль, что все это лишнее - система уже практически и не падает (сам уже года 2 как вообще перестал делать backup системы, только важной документации) .... а у новичков больше проблем по отладке приложений, а это уже совсем другое ...

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

Romshot	# 7 лет, 9 месяцев назад (отредактировано 7 лет, 9 месяцев назад)
Темы: 1 Сообщения: 50 Участник с: 06 октября 2016	vasek Но гложет мысль, что все это лишнее - система уже практически и не падает (сам уже года 2 как вообще перестал делать backup системы, только важной документации) .... а у новичков больше проблем по отладке приложений, а это уже совсем другое ... Не сомневайтесь. Эта статья - отличная идея. Лично я, как приду домой, обязательно всё внимательно прочитаю и добавлю в закладки. Это, конечно, не инструкция по выживанию, но кому-то это точно понадобится. Я (да и не только я), к примеру, пополню свои знания о системе (изучение системы и притянуло меня к лину, арче). По поводу стабильности системы в целом, то, если не считать проблем в результате моих экспериментов, то из проблем с системой, было разве что отвал груба 2-3 года тому назад. И, конечно, спасибо за статью

Romshot

# 7 лет, 9 месяцев назад (отредактировано 7 лет, 9 месяцев назад)

Темы: 1

Сообщения: 50

Участник с: 06 октября 2016

vasek
Но гложет мысль, что все это лишнее - система уже практически и не падает (сам уже года 2 как вообще перестал делать backup системы, только важной документации) .... а у новичков больше проблем по отладке приложений, а это уже совсем другое ...

Не сомневайтесь. Эта статья - отличная идея. Лично я, как приду домой, обязательно всё внимательно прочитаю и добавлю в закладки. Это, конечно, не инструкция по выживанию, но кому-то это точно понадобится. Я (да и не только я), к примеру, пополню свои знания о системе (изучение системы и притянуло меня к лину, арче). По поводу стабильности системы в целом, то, если не считать проблем в результате моих экспериментов, то из проблем с системой, было разве что отвал груба 2-3 года тому назад.
И, конечно, спасибо за статью

vasek	# 7 лет, 9 месяцев назад
Темы: 47 Сообщения: 11853 Участник с: 17 февраля 2013	Добавил ........ Проблемы с выключением Ошибки не исчезают с опытом - они просто умнеют

R.V.	# 7 лет, 8 месяцев назад
Темы: 11 Сообщения: 1100 Участник с: 10 января 2017	У нас там закрыли одну интересную тему из-за неадекватного пользователя, к сожалению. А можно немножко подробнее осветить вопрос ремонта установленной системы из Live CD?

R.V.	# 7 лет, 8 месяцев назад
Темы: 11 Сообщения: 1100 Участник с: 10 января 2017	Полезная информация