vasek |
|
Темы:
48
Сообщения:
11320
Участник с: 17 февраля 2013
|
Иногда возникают ситуации, в которых при решении проблем не хватает информации, точнее логов journal и Xorg не достаточно, а как получить дополнительно не понятно. Отдельной подборки материалов на данную тематику, где бы все это было в одном месте, нет … да, в принципе, и нагулить это не просто. Вот и решил описать некоторые способы добычи этой информации. 1. Начнем с самого простого udev, который имеет конфигурационный файл /etc/udev/udev.conf, в котором есть одна строчка которая и определяет уровень логирования udev - по дефолту стоит уровень info. Если мы хотим больше информации, то следует изменить эту строчку на следующую В результате этого уровень логирования journal возрастет, чтобы не утонуть в логах их можно фильтровать, например, так journalctl -b | grep -i udev или по другому.Не забываем после отладки вернуть все на место. 2. Отладка unit systemd 2.1 Имеется стандартный простой способ для увеличения логирования отдельного системного unit, находящегося в директории /usr/lib/systemd/system/ - необходимо добавить опцию -d (от слова debug) в строке запуска юнита. Например, для /usr/lib/systemd/system/bluetooth.service имеем cat /usr/lib/systemd/system/bluetooth.service | grep ExecStart а чтобы увеличить логирование добавим опцию -d и строка примет вид и не забываем systemctl daemon-reload (при необходимости и restart сервиса)Отмечу, что иногда это не срабатывает, да и порой не дает нужной информации. В этом случае лучше использовать более тяжелый инструмент, который описан далее. 2.2. Применение strace Для этого способа используем следующий запуск unit, например, имеем cat /usr/lib/systemd/system/systemd-vconsole-setup.service | grep ExecStart и после изменения строка примет вид используемые опции strace в зависимости от ситуации, а имя лога на Ваш вкус.И не забываем systemctl daemon-reload (при необходимости и restart сервиса) PS - Разумеется можно редактировать тот же сервис в другой стандартной директории /etc/systemd/system/ и не забываем потом вернуть все обратно ... 3. Xorg - здесь имеется несколько способов - и простые и сложные. Простые приводят к простому увеличению логирования от которого мало толку, а потому их не описываю. Приведу не стандартный способ трассировки с использованием strace. Если используется DM, то лучше его временно отключить и использовать .xinitrc (то есть startx). Загружаемся в текстовую консоль (Х-ы не запускаем), меняем файл /etc/X11/xinit/xserverrc, например, приводим к виду (изменив на нужное) cat /etc/X11/xinit/xserverrc
PS - делаем отладку по усмотрению, в зависимости от ситуации … например, в данном случае используется опция -T, которая позволяет посмотреть как долго выполняется каждый системный вызов. Название лога на Ваше усмотрение. Сохраняем и стартуем Х-ы - не пугаемся, время загрузки увеличится, НО сразу после загрузки убиваем (выходим) Х-ы и приводим файл /etc/X11/xinit/xserverrc к нормальному виду, точнее возвращаем все на место (Х-ы нужно убить, так как они запущены через strace, убить которй не получится - вообщем проще убить Х-ы и вернуться в текстовую консоль) cat /etc/X11/xinit/xserverrc Можно просто не нужную строку закоментировать, а нужную раскоментировать.Снова загружаем Х-ы и анализируем файл strace_X.log, в котором в конце каждой строки будет указано время выполнения системного вызова, типа такого … ну и ищем строки с большим временем … (здесь же будут и проги автозапуска, например, здесь показан tilix)Повторюсь, использование опций strace зависит от обстоятельств расследования. При желании вместо strace можно использовать более мощный комбайн - sysdig, но работать с ним сложнее. 4. Драйвера/модули И в конце привожу, как можно получить информацию в случае проблем с драйверами/модулями - обычно возникает при выходе из suspend/hibernate … иногда и при загрузке. Способ заключается в передаче параметра ядра initcall_debug при загрузке, в результате чего в dmesg будет сохранена информация каждого initcall, который используется для инициализации статически связанных драйверов ядра и подсистем, и будет возможность получить информацию о времени загрузки этих драйверов/модулей. Вообщем, прописываем параметр initcall_debug, лучше прямо при загрузке, перейдя в консоль Grub (нажимаем e в меню Grub) и загружаемся. В логах будут строки о загрузке модулей, они разбросаны, искать их тяжело, но для одного модуля, например, ath3k можно посмотреть так dmesg | grep ath3k В последней строчке видим returned 0 (то есть успешно) и затрачено времени 23011 микросекунд.Но в одной статье приведена интересная команда для вытаскивания этой информации из dmesg и получим отсортированный вывод с одной строчкой для каждого модуля, типа такого
Один нюанс - использование initcall_debug увеличивает количество сообщений, генерируемых ядром во время загрузки системы. Рекомендуют увеличить размер буфера журнала printk, чтобы избежать переполнения буфера журнала. Правда я с таким не сталкивался. ДОПОЛНЕНИЕ - Уточнение в части информативности Xorg - конечно, не совсем удобно редактировать файл /etc/X11/xinit/xserverrc, чтобы прописать запуск strace, а затем убивать Х-ы …. намного удобнее ничего этого не делать, а просто из текстовой консоли запустить sysdig, а затем startx …, то есть загружаемся в текстовую консоль и далее ... sudo sysdig -w ~/sysdig.log стартуем Х-ы, после загрузки убиваем sysdig, для чего сначала узнаем PID sysdig, а потом к этому PID применяем kill ... pidof sysdig 28360 sudo kill 28360 Проверяем pidof sysdig … пусто … Для чего убивать sysdig - утилита запущена и собирает информацию - если процесс не убить, то лог sysdig будет постоянно увеличиваться в размерах и может забить весь диск. Посмотрим на созданный лог и его объем du -m ~/sysdig.log 18 /home/vasek/sysdig.log И видим, что файл довольно большой, 18 М (это всего то за несколько секунд), но в нем записаны все процессы/события за данный промежуток времени. Анализируя данный файл можно получить любую информацию, но для этого нужно знать как это делать, то есть нужно изучать sysdig. В принципе sysdig можно успешно использовать и в работающй системе, чтобы найти возможные проблемы. ... Сылка для начального ознакомления с sysdig ...
Ошибки не исчезают с опытом - они просто умнеют
|