General troubleshooting (Русский)

From ArchWiki
Состояние перевода: На этой странице представлен перевод статьи General troubleshooting. Дата последней синхронизации: 15 февраля 2022. Вы можете помочь синхронизировать перевод, если в английской версии произошли изменения.

Ссылки по теме

General troubleshooting - Устранение общих неполадок в системе. Эта статья дает советы по устранению общих проблем. Для решения проблем, связанных с конкретной программой, посетите соответствующую страницу Wiki.

Общие процедуры

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

  1. Запустите приложение в терминале, чтобы можно было просмотреть, что оно выводит в stdout/stderr.
    1. Включите более подробный вывод информации (обычно для этого у приложения есть параметр вроде --verbose/-v/-V или --debug/-d), если информации всё ещё недостаточно для отладки.
    2. Иногда такого параметра нет, и нужно включать подробный вывод в файле настроек приложения.
    3. Приложение также может записывать информацию в файл журнала. Обычно журналы располагаются в /var/log, $HOME/.cache или $HOME/.local.
    4. Если в приложении нет возможности включить подробный вывод, всегда можно запустить strace и другие подобные программы.
  2. Проверьте журнал systemd. Возможно, ошибка оставила следы и в этом журнале, особенно если она влияет на другие приложения.
    1. dmesg показывает сообщения из кольцевого буфера ядра. Это полезно, если диск по какой-то причине недоступен, но этот журнал может быть неполным, так как размер буфера ограничен. По возможности используйте journalctl.
    2. journalctl имеет больше опций по поиску и фильтрации сообщений, чем dmesg, и по умолчанию использует человекочитаемые временные метки.
  3. Всегда рекомендуется проверять соответствующие баг-трекеры, чтобы узнать, известна ли ваша проблема и есть ли её решение.
    1. В зависимости от того, что предпочитают разработчики, обычно есть баг-трекер, а иногда и форум или даже, например, IRC-канал.
    2. Существует баг-трекер Arch Linux, который следует использовать в первую очередь для ошибок в создаваемых пакетах.

Дополнительная поддержка

Если вам нужна дополнительная поддержка, вы можете спросить об этом на форуме] или в IRC.

Примечание: Поддержка предоставляется ТОЛЬКО для Arch Linux, не для дистрибутивов, основанных на Arch.

При обращении за поддержкой публикуйте полный вывод/журнал, а не только те участки, которые вы считаете важными. Пригодится следующая информация:

  • Полный вывод всех задействованных команд — не выбирайте только то, что считаете нужным.
  • журнал systemd.
    • Для более подробного вывода используйте параметр загрузки systemd.log_level=debug. Логов станет очень много, поэтому включайте его только при необходимости.
    • Не используйте параметр -x, поскольку он загромождает вывод и затрудняет его чтение.
    • Используйте параметр -b, если не требуются журналы предыдущих загрузок. Отсутствие этого параметра может вывести очень много старых логов, которые могут даже оказаться слишком большими для pastebin-сервисов.
  • Релевантные файлы конфигурации
  • Задействованные драйверы
  • Версии связанных с проблемой пакетов
  • Журнал ядра: journalctl -k или dmesg (для запуска обоих нужны права root).
  • Xorg: в зависимости от установки, используемый экранный менеджер тоже может иметь значение.
    • Xorg.log может быть расположен в одном из нескольких мест: системный журнал, /var/log/ или $HOME/.local/share/xorg/.
    • Некоторые экранные менеджеры, например LightDM, также могут помещать Xorg.log в свой собственный каталог журналов.
  • Pacman: Если недавнее обновление что-то сломало, посмотрите в /var/log/pacman.log.
    • Может быть полезно использовать параметр --debug.

Один из лучших способов опубликовать эту информацию — использовать pastebin.

Pastebin-сервис выдаст вам ссылку, которую можно будет отправить на форум или в IRC.

Также рекомендуется прочитать: how to properly report issues.

Проблемы загрузки

При диагностике проблем с загрузкой очень важно знать, на каком этапе происходит сбой.

  1. Прошивка (UEFI или BIOS)
    1. Обычно имеет только базовые инструменты для отладки.
    2. Убедитесь, что Secure Boot отключен.
  2. Загрузчик
    1. Одна из самых распространённых операций здесь — изменение параметров ядра.
  3. initramfs
    1. Обычно предоставляет аварийную оболочку (emergency shell).
    2. В зависимости от выбранных хуков, в ней доступен либо dmesg, либо журнал.
  4. Собственно система
    1. В зависимости от того, насколько сильно она повреждена, здесь может быть достаточно простого вызова оболочки восстановления.

К сожалению, инструментов отладки, предоставляемых любым этапом, может быть недостаточно для исправления сломанного компонента. В этом случае для восстановления может быть использован archiso.

Сообщения консоли

После процесса загрузки экран очищается и появляется приглашение к входу в систему, из-за чего пользователи не могут прочитать вывод init и сообщения об ошибках. Это поведение по умолчанию может быть изменено с помощью методов, описанных в следующих разделах.

Обратите внимание, что, независимо от выбранного варианта, сообщения ядра можно посмотреть после загрузки с помощью journalctl -k или dmesg. Для отображения всех журналов текущей загрузки используйте journalctl -b.

Управление потоком

Это базовое управление, которое применимо к большинству эмуляторов терминала, включая виртуальные консоли (VC):

  • Нажмите Ctrl+s, чтобы приостановить вывод.
  • И Ctrl+q, чтобы возобновить его.

Это приостанавливает не только вывод, но и программы, которые пытаются печатать на терминал, поскольку вызовы write() будут блокироваться, пока вывод приостановлен. Если ваш init выглядит зависшим, убедитесь, что системная консоль не приостановлена.

Чтобы увидеть сообщения об ошибках, которые уже были выведены на экран, смотрите getty (Русский)#Отображение загрузочных сообщений на tty1.

Отладочный вывод

Большинство сообщений ядра скрыты во время загрузки. Вы можете увидеть больше сообщений, добавляя различные параметры ядра. Самые простые из них:

  • debug включает отладочные сообщения как для ядра, так и для systemd
  • ignore_loglevel заставляет печатать все сообщения ядра.

Можно добавить и другие параметры, которые могут быть полезны в определённых ситуациях:

  • earlyprintk=vga,keep печатает сообщения ядра в самом начале процесса загрузки, в случае, если ядро аварийно завершает работу до появления вывода. Вы должны изменить vga на efi для систем EFI.
  • log_buf_len=16M выделяет больший (16 МиБ) буфер сообщений ядра, чтобы гарантировать, что отладочный вывод не будет перезаписан.

Существуют также параметры для включения отладки определённых подсистем, например bootmem_debug, sched_debug. Кроме того, initcall_debug может быть полезен для исследования зависаний загрузки. (Ищите вызовы, которые не завершились.) Более подробная информация есть в документации по параметрам ядра.

netconsole

netconsole — это модуль ядра, который отправляет все сообщения журнала ядра (например, dmesg) по сети на другой компьютер, не задействуя userspace (например, syslogd). Название "netconsole" не очень корректное, так как на самом деле это не консоль, а скорее служба удалённого логирования.

Он может быть как встроен ядро, так и подключаться отдельным модулем. Встроенный netconsole инициализируется сразу после включения сетевой карты и вызовет указанный интерфейс как можно скорее. Модуль в основном используется для перехвата паники ядра на headless-машине или в других ситуациях, когда userspace неработоспособен.

Оболочки восстановления

Попадание в оболочку восстановления (recovery shell) в процессе загрузки может помочь вам точно определить, где и почему что-то не работает. Есть несколько связанных с этим параметров ядра, но все они запускают обычную оболочку, из которой можно выйти, чтобы ядро продолжило свою работу:

  • rescue запускает оболочку вскоре после перемонтирования корневой файловой системы чтение/запись
  • emergency запускает оболочку ещё раньше, до того, как большинство файловых систем будут смонтированы
  • init=/bin/sh (в крайнем случае) изменяет программу init на командную оболочку, которая запустится от имени root. И rescue, и emergency полагаются на systemd, а подмена init будет работать, даже если systemd сломан.

Другим вариантом является debug-shell от systemd, который добавляет root shell на tty9 (переключиться туда можно с помощью Ctrl+Alt+F9). Его можно включить, либо добавив systemd.debug_shell в параметры ядра, либо включив debug-shell.service.

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

Отладка модулей ядра

Смотрите Модуль ядра#Получение информации.

Отладка оборудования

Отладка зависаний

К сожалению, зависания обычно трудно отладить, а некоторые из них требуют много времени для воспроизведения. Некоторые зависания относительно просты в отладке:

  • Продолжает ли играть звук? Если да — видимо, просто завис экран. Это могут быть проблемы с видеодрайвером.
  • Отвечает ли компьютер на запросы? Попробуйте подключиться по SSH, если переключение в консоль не работает.
  • Индикатор HDD (если есть) показывает высокую нагрузку на диск? Вероятно, используется слишком много памяти и система начала активно использовать файл подкачки. Смотрите ответ на StackExchange для получения информации о зависании при большой записи.

Если ничего из этого не подходит, попробуйте выполнить корректное завершение работы. Одиночное короткое нажатие на кнопку выключения отправит системе сигнал завершения работы, после чего она может отвиснуть и показать экран завершения работы. Если кнопка выключения не помогает, можно попробовать выполнить корректное завершение работы с помощью SysRq. Корректное завершение очень важно, чтобы журнал записал имеющиеся сообщения на диск. При нештатном выключении компьютера последние сообщения в журнале могут быть потеряны, а вместе с ними может потеряться и информация о проблеме. Из-за этого полные зависания компьютера труднее в отладке.

Удалённое чтение журнала может помочь, если зависание не позволяет записать что-либо на диск. Самое простое и примитивное решение для базовой отладки может быть таким: 

$ ssh зависающий_хост journalctl -f

Многие фатальные зависания, при которых вся система больше не отвечает и требует принудительного выключения, могут быть связаны с ошибками в прошивке, драйверах или железе. Попробуйте другое ядро (смотрите Ядро#Отладка регрессий) или даже другой дистрибутив Linux или операционную систему, обновите прошивку и запустите диагностику оборудования, это может помочь найти проблему.

Совет: Рекомендуется попробовать обновить прошивку, так как обновления могут устранить странные проблемы.

Если зависание не позволяет собрать какие-либо журналы или другую информацию, необходимую для отладки, попробуйте воспроизвести зависание через LiveCD. Если для воспроизведения зависания требуется графическая среда или если зависание может быть воспроизведено на archiso, используйте LiveCD другого дистрибутива, желательно не основанного на на Arch Linux, чтобы исключить возможность того, что зависание связано с версией или патчами ядра. Если зависание всё ещё происходит даже в LiveCD, возможно, это проблемы с железом. Если же зависания больше нет, нужно разобраться в различиях между системами. Различные конфигурации, различия в версиях и параметрах ядра и другие подобные изменения могли устранить зависание.

Однако мигающий светодиод caps lock может указывать на панику ядра. Некоторые установки могут не показывать консоль, когда произошла паника ядра, что может сбить с толку и быть интерпретировано как другой вид зависания.

Отладка регрессий

Важно: Как правило, это приводит к частичному обновлению, которое является необходимым злом в данном конкретном случае. Действуйте осторожно и подготовьте способ восстановления системы на случай, если этот сценарий не позволит нормально загрузиться.

Если обновление вызывает проблему, но понижение версии конкретного пакета устраняет её — скорее всего, это регрессия. Наиболее важной частью отладки регрессий является проверка того, была ли проблема уже исправлена, поскольку это может сэкономить много времени. Для этого сначала убедитесь, что приложение полностью обновлено (например, убедитесь, что приложение имеет ту же версию, что и в официальных репозиториях). Если оно уже обновлено или если обновление не устраняет проблему, попробуйте использовать актуальную последнюю версию, обычно версию -git, которая может быть доступна в AUR. Если это устранит проблему, а версии с исправлениями ещё нет в официальных репозиториях, подождите, пока новая версия не появится в них, а затем перейдите на неё.

Если проблема не исчезла, отладьте её и/или проведите bisect и отправьте сообщение об ошибке в баг-трекер программы, чтобы разработчики узнали о ней и смогли её исправить.

Примечание: Для ядра нужен немного другой поход к отладке регрессий.

Не получается использовать подключаемые устройства после обновления ядра

Чаще всего (но не только) это проявляется как:

  • только что подключенные USB-накопители отображаются в dmesg, но отсутствуют в /dev/,
  • не получается использовать проводное/беспроводное соединение на ноутбуке, если оно ещё не использовалось перед обновлением ядра,
  • modprobe выдаёт ошибку FATAL: Module модуль not found in directory /lib/module/версияядра при попытке загрузить модуль, который ещё не использовался перед обновлением ядра.

Как частично описано в разделе Обслуживание системы#Перезагружайтесь после обновлений, ядро будет обновлено не в момент обновления пакета, а только после перезагрузки. При этом модули ядра, расположенные в каталоге /usr/lib/module/версияядра/, удаляются pacman'ом при установке нового пакета ядра. Как объясняется в FS#16702, такой подход позволяет не оставлять в системе файлы, не обрабатываемые менеджером пакетов, но приводит к вышеупомянутым симптомам. Чтобы устранить их, перезагружайтесь после обновления ядра. Более хорошим решением, которое ещё не реализовано, будет использование разных пакетов для разных версий ядра: основная проблема заключается в том, как обрабатывать удаление предыдущих версий ядра, когда они больше не нужны.

Другое решение доступно в виде kernel-modules-hook, где два хука pacman используют rsync для сохранения модулей ядра в файловой системе после обновления ядра, а служба systemd удаляет старые модули через четыре недели после этого.

Менеджер пакетов

Смотрите общие решения проблем и решение проблем с PGP-ключами.

Исправление сломанной системы

Если выполнялось частичное обновление, в первую очередь попробуйте обновить всю систему целиком. Может потребоваться перезагрузка. 

# pacman -Syu

Если вы обычно загружались в графический интерфейс, а сейчас он не работает, можно попробовать попасть в консоль с помощью Ctrl+Alt+F1 - Ctrl+Alt+F6 и в ней запустить pacman.

Если система сломана настолько, что вы не можете запустить pacman, загрузите Arch ISO с USB-накопителя, компакт-диска или по сети через PXE. (Выполнять остальные шаги по установке системы не нужно.)

Загрузившись в Arch ISO, примонтируйте корневую файловую систему: 

[ISO] # mount /dev/устройство /mnt

Примонтируйте внутри /mnt другие нужные разделы, если вы их создавали, например: 

[ISO] # mount /dev/bootУстройство /mnt/boot

Затем попробуйте зайти в chroot и запустить pacman в нём: 

[ISO] # arch-chroot /mnt
[chroot] # pacman -Syu

Если это не работает, выйдите из chroot и попробуйте: 

[ISO] # pacman -Syu --sysroot /mnt

Если и это тоже не работает, попробуйте: 

[ISO] # pacman -Syu --root /mnt --cachedir /mnt/var/cache/pacman/pkg

Совместная отладка в IRC

Смотрите IRC#Collaborative debugging.

fuser

fuser это утилита командной строки для определения процессов использующих ресурсы, таких как файлы, файловые системы и порты TCP / UDP.

fuser содержится в пакете psmisc, который должен быть уже установлен как часть мета-пакета base. Подробности есть в fuser(1).

Разрешения сессии

Примечание: Вы должны использовать systemd в качестве системы инициализации работы локальных сеансов [1] - которая необходима для разрешения polkit и ACL для различных устройств (смотрите /usr/lib/udev/rules.d/70-uaccess.rules и [2])

Во-первых, убедитесь, что у вас есть действующий локальный сеанс X: 

$ loginctl show-session $XDG_SESSION_ID

Должны получить на выходе Remote=no и Active=yes. Если это не так, убедитесь, что X работает на томже tty, где и произошел вход. Это нужно чтобы сохранить сеанс logind. Который обрабатывается по умолчанию /etc/X11/xinit/xserverrc.

Основные polkit действия не требуют дальнейшей настройки. Некоторые действия polkit требуют дальнейшей проверки подлинности, даже при местной сессии. Для этой работы агент аутентификации polkit должен быть запущен. Смотрите больше информации по polkit#Authentication agents.

Ошибка при загрузке разделяемых библиотек

Если при использовании программы, вы получите сообщение об ошибке подобное: 

error while loading shared libraries: libusb-0.1.so.4: cannot open shared object file: No such file or directory

Воспользуйтесь pacman или pkgfile для поиска пакета, которому принадлежит недостающая библиотека: 

$ pacman -F libusb-0.1.so.4
extra/libusb-compat 0.1.5-1
    usr/lib/libusb-0.1.so.4

В этом случае должен быть установлен пакет libusb-compat. Также может оказаться, что зависимую программу нужно пересобрать после обновления библиотеки до новой версии (soname bump).

Ошибка также может означать, что пакет, который вы использовали для установки программы не перечисляет библиотеку в качестве зависимости в его PKGBUILD: если это официальный пакет, сообщите об ошибке; если это пакет AUR, сообщите об этом сопровождающему на странице пакета в AUR.

Смотрите также