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

Смотрю новички теряются, когда у них падает система — не могут даже посмотреть логи, откатиться и др.
Написано наспех ..... возможны и ошибки ...... прошу строго не судить ...
Чтобы ориентироваться в причинах сбоя/падения системы, желательно знать на каком этапе загрузки произошел сбой — это, можно сказать, половина успеха. А потому необходимо знать этапы начальной загрузки системы, которые хорошо описаны и разбирать их не будем.
Простейшую схему загрузки (без 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, но один большой минус — не отображается кирилица.
Но чтобы предпринять более существенные действия по восстановлению системы, возможному подключению интернета и другим действиям, желательно активировать 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........ но это на любителя и не забывайте, что этот сервис дает полный доступ к системе.

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

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

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

1. Долгое выключение — получаем лог shutdown и анализуруем его (смотрим тайм-ауты и др.). Для получения лога
- создаем скрипт /usr/lib/systemd/system-shutdown/debug.sh (не забыть сделать его исполняемым):
#!/bin/sh
mount -o remount,rw /
dmesg > /var/log/shutdown.log
mount -o remount,ro /
- перегружаемся со следующими параметрами:
systemd.log_level=debug systemd.log_target=kmsg log_buf_len=1M
- выключаем ….... включаем и анализируем файл /var/log/shutdown.log
Начало завершения/выключения — ищем строку типа 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 и смотрим его работу …
Очень даже полезная тема! +1
Истина где-то рядом...
Насчет о возможности отката пакетов ..... лучше даю ссылку из одного топика по обсуждению упавшей системы
lo7ev
Зашел через emergency откатил linux, linux-headers, acpi_call, systems. Все починилоь
ИМХО, но здесь немного не место, где подобную инструкцию можно разместить. Может запилить совместными усилиями на вики? Во всяком случае, там можно будет алгоритм хорошо структурировать, а еще, после хорошего допила и на главной разместить, поскольку очень полезная идея.
vasek спасибо!
Romshot
ИМХО, но здесь немного не место, где подобную инструкцию можно разместить. Может запилить совместными усилиями на вики? Во всяком случае, там можно будет алгоритм хорошо структурировать, а еще, после хорошего допила и на главной разместить, поскольку очень полезная идея.
В принципе это не инструкция, просто приведены основные положения/направления ....... чтобы можно было от чего то оттолкнуться .... всего не опишешь, все варианты не предусмотришь … и предстоит дополнительное и гугление и анализ ...
Имеется много чего по отладке, но все это раскидано. Думал постепенно дополнять ...
Но гложет мысль, что все это лишнее - система уже практически и не падает (сам уже года 2 как вообще перестал делать backup системы, только важной документации) .... а у новичков больше проблем по отладке приложений, а это уже совсем другое ...
vasek
Но гложет мысль, что все это лишнее - система уже практически и не падает (сам уже года 2 как вообще перестал делать backup системы, только важной документации) .... а у новичков больше проблем по отладке приложений, а это уже совсем другое ...
Не сомневайтесь. Эта статья - отличная идея. Лично я, как приду домой, обязательно всё внимательно прочитаю и добавлю в закладки. Это, конечно, не инструкция по выживанию, но кому-то это точно понадобится. Я (да и не только я), к примеру, пополню свои знания о системе (изучение системы и притянуло меня к лину, арче). По поводу стабильности системы в целом, то, если не считать проблем в результате моих экспериментов, то из проблем с системой, было разве что отвал груба 2-3 года тому назад.
И, конечно, спасибо за статью
Добавил ........ Проблемы с выключением
У нас там закрыли одну интересную тему из-за неадекватного пользователя, к сожалению. А можно немножко подробнее осветить вопрос ремонта установленной системы из Live CD?
Истина где-то рядом...
Полезная информация
Истина где-то рядом...
 
Зарегистрироваться или войдите чтобы оставить сообщение.