Как выяснить причину отсутствия реакции на Linux?

1239
A. Donda

Я прошу прощения, что проблема, о которой я пишу, не очень конкретна. Я использую KDE4 для тестирования Debian и очень часто использую файловый менеджер KDE Dolphin, большую часть времени без проблем. Я полагаю, что в последнее время после обновления системы Dolphin часто очень не отвечает. Это может произойти непосредственно при запуске - примерно за минуту до появления окна - это может произойти и позже, через некоторое время все было хорошо. Содержимое окна больше не обновляется, проходит много времени, пока файл не открывается после нажатия на него и т. Д. Перезагрузка иногда устраняет проблему, но ненадолго. Я думал, что это может быть связано с доступом к оптическому приводу, но проблема остается, даже если в приводе нет носителя. - У меня нет смонтированных сетевых файловых систем. Также нет других процессов, потребляющих процессорное время и / или пропускную способность диска.

Теперь вопрос, который я задаю, не об этой конкретной проблеме с Дельфином, а об этом:

Как я вообще могу справиться с ситуацией, когда программа перестает отвечать на запросы? Существует ли стандартная стратегия для выяснения причин такой проблемы, чтобы 1) я мог найти исправление или обходной путь для себя и / или 2) иметь возможность представить полезный отчет об ошибке?

В этом случае, поскольку я думал, что это может быть связано с попыткой Dolphin получить доступ к определенным файлам и зависанием, потому что есть какой-то блок, я запустил Dolphin straceи попытался разобраться в сообщениях. Тем не менее, существует множество «ошибок» типа «EAGAIN (ресурс временно недоступен)» или «ENOENT (нет такого файла или каталога)», большинство из которых, по-видимому, не представляют проблему. Единственное, чему я научился достоверно, это то, что даже если Дельфин не реагирует на ввод пользователя, это не значит, что в ответ на движения мыши и щелчки мышью ничего не происходит ...

Это straceправильный инструмент? Если да, что я должен искать в его выводе? Если нет, что я должен использовать вместо этого?

1

1 ответ на вопрос

1
r0berts

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

htop 

Если вы хотите, чтобы плохо реагирующая система вернулась в рабочее состояние, то одна из самых полезных программ, которые я нашел, - это htop. В основном это показывает использование системы в режиме реального времени в терминале. Вы должны прочитать об этом немного - это очень хорошо задокументировано, и об этом было опубликовано немало статей. Вы используете его в терминале, поэтому, если ваш рабочий стол завис, но если вы все еще можете войти в свой компьютер через ssh, он работает. Например, из вашей машины Windows через PUTTY. Он дает вам список процессов и показывает наиболее важную информацию о них. С F6 вы сортируете процессы по определенному использованию ресурсов (например, процессор, память, подкачка) и, таким образом, вы можете увидеть, какая программа является источником ресурсов. С помощью F4 вы можете фильтровать по имени программы - просто начните печатать. F5 покажет вам дерево процессов и, скорее всего, покажет, какие файлы открыты вашей программой. С F9 вы можете отправить любой сигнал KILL, который вы хотите в программу. Хорошая вещь - вы можете просто перемещаться вверх и вниз с помощью клавиш со стрелками и нажимать цифры, чтобы выбрать опции - вы должны немного поэкспериментировать, чтобы оценить это.

Мое эмпирическое правило: если система не зависла так сильно, что нажатие кнопки Num Lock не мигает индикатором NumLock, то есть вероятность, что некоторые простые исследования и - SIGHUP или SIGKILL из htop вернут ее к стабильности. Если ситуация повторится - тогда вы можете заполнить отчет об ошибке.

Привет r0berts, спасибо за ваш ответ. Дело в том, что заморожена не система или рабочий стол, а именно эта конкретная программа. Я использовал `top`, чтобы посмотреть состояние системных ресурсов, и не смог найти ничего необычного. `htop` выглядит очень красиво, спасибо за совет! Но я не думаю, что это осветит эту проблему. И хотя я далеко не профессиональный программист, я не совсем невежественен. Итак, у вас есть идея, как я мог бы идентифицировать проблему с одной программой, где зависание не связано с высокой загрузкой процессора, памяти или пропускной способности? A. Donda 10 лет назад 0
Привет, да, я думаю, что я попадаю в одну категорию - не программист, но не совсем невежественный. Если ресурсы не являются проблемой, то мы, вероятно, думаем о каком-то другом сбое в программировании. Еще пара инструментов, чтобы посмотреть, что именно происходит с дельфином, - это псидофдоолфин. r0berts 10 лет назад 0
Извините за пред. Еще пара полезных инструментов: ** lsof ** `lsof pidOFdoolphin` (получить pid из` top` или `pidof`). Это будет видеть файлы, открытые дельфином. ** Wireshark **, чтобы увидеть, есть ли исходящие запросы, которые никогда не возвращаются; файловые менеджеры часто ждут, пока сеть истечет, и это может выглядеть как зависание. Может быть глюк в программе или плагине. Выключите сеть и посмотрите, происходит ли то же самое. ** nmon ** - еще один полезный способ взглянуть на вашу систему. Плюс интересная дискуссия на форуме, описывающая несколько сходных условий [ссылка] (http://forum.kde.org/viewtopic.php?f=63&t=92253) r0berts 10 лет назад 1
Когда вы придете к решению, возможно, вы могли бы опубликовать его здесь. Интересно, почему программа (широко используемая при этом) перестает отвечать на запросы и не оказывает никакого влияния на системные ресурсы или работу в сети. r0berts 10 лет назад 1

Похожие вопросы