Метод для диагностирования катастрофических отказов Ubuntu?

Я - несколько нетехнический пользователь рабочего стола, выполняющего 14.04 LTS. Я работал в Ubuntu в течение нескольких лет. Аппаратные средства несколько стары.

Иногда я испытываю технические вопросы с Ubuntu - обычно это - замедление или замораживание, но недавно (т.е. на прошлой неделе) у меня был частый перезапуск Единицы (который вытирает все запущенные приложения и требует входа в систему).

Мне пришло в голову, что я понятия не имею, как диагностировать проблему как это - или любые системные проблемы катастрофических отказов. Я не знаю инструменты или даже метод для диагностирования вещей.

Единственной вещью, которую я использовал для проблем системы контроля, является htop. От этого я вижу периодические скачки в ЦП и Памяти - обычно для Firefox и Amarok и хрома, но иногда с compiz или некоторая загадочная системная команда (как "X базовых:0 - место...." извините я не знаю, как скопировать вывод с htop).

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

Я открыл dmesg и var/журнал/системный журнал, но признаюсь, что не знаю, как интерпретировать данные.

dmesg мог бы иметь интересные данные, но я не знаю, как выяснить метку времени. Я сортирую, понимают системный журнал, но у меня нет достаточного опыта знать, какое сообщение об ошибке является значительным и что делать с этим:

Вот, например, системный журнал для последнего катастрофического отказа менеджера окон:

  $(/usr/lib/php5/maxlifetime))
Jan 30 19:17:01 robert-KJ379AA-ABA-a6400f CRON[4048]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Jan 30 19:33:29 robert-KJ379AA-ABA-a6400f wpa_supplicant[992]: message repeated 29 times: [ wlan1: CTRL-EVENT-SCAN-STARTED ]
Jan 30 19:34:21 robert-KJ379AA-ABA-a6400f wpa_supplicant[992]: wlan1: WPA: Group rekeying completed with 74:9d:dc:5f:32:b1 [GTK=TKIP]
Jan 30 19:35:29 robert-KJ379AA-ABA-a6400f wpa_supplicant[992]: wlan1: CTRL-EVENT-SCAN-STARTED 
Jan 30 19:39:01 robert-KJ379AA-ABA-a6400f CRON[4123]: (root) CMD (  [ -x /usr/lib/php5/maxlifetime ] && [ -x /usr/lib/php5/sessionclean ] && [ -d /var/lib/php5 ] && /usr/lib/php5/sessionclean /var/lib/php5 $(/usr/lib/php5/maxlifetime))
Jan 30 19:59:22 robert-KJ379AA-ABA-a6400f kernel: [ 7911.658443] [drm:radeon_gem_object_create] *ERROR* Failed to allocate GEM object (4096, 2, 4096, -12)
Jan 30 19:59:29 robert-KJ379AA-ABA-a6400f kernel: [ 7918.797835] chrome invoked oom-killer: gfp_mask=0x0, order=0, oom_score_adj=200
Jan 30 19:59:29 robert-KJ379AA-ABA-a6400f kernel: [ 7918.797842] chrome cpuset=/ mems_allowed=0
Jan 30 19:59:29 robert-KJ379AA-ABA-a6400f kernel: [ 7918.797846] CPU: 1 PID: 2837 Comm: chrome Not tainted 3.13.0-76-generic #120-Ubuntu`

Я подозреваю, что катастрофический отказ произошел в Jan 30 19:39:01, потому что это - самый большой разрыв времени. Первым сообщением после катастрофического отказа является Radeon (видеокарта) сообщение, и это кажется вероятным преступником, но с другой стороны, я предполагаю, что использование памяти/CPU также играет фактор. Кроме того, Вы ожидали бы, что данные катастрофического отказа обнаружатся ПОСЛЕ катастрофического отказа?

Это единственные инструменты для выяснения проблемы? Есть ли какие-либо методы для сужения проблемы к аппаратным средствам/приложению/системному пространству?

ОБНОВЛЕНИЕ: Другой катастрофический отказ с большим количеством сообщений об ошибках, указывающих compiz/window отказ менеджера. (Я Понятия не имею, как решить это). Вот некоторый материал из системного журнала:

Jan 31 11:39:28 robert-KJ379AA-ABA-a6400f kernel: [64317.672548] [drm:radeon_gem_object_create] *ERROR* Failed to allocate GEM object (1048576, 2, 4096, -23 
Jan 31 11:39:28 robert-KJ379AA-ABA-a6400f kernel: [64317.672591] compiz[15437]: segfault at 0 ip 00007f5e027bd7b6 sp 00007ffe329bf9c0 error 6 in r600_dri.so[7f5e0254d000+399000]
Jan 31 11:39:39 robert-KJ379AA-ABA-a6400f gnome-session[15215]: WARNING: Child process 15437 was already dead.
Jan 31 11:39:39 robert-KJ379AA-ABA-a6400f gnome-session[15215]: WARNING: Application 'compiz.desktop' killed by signal 11
    Jan 31 11:39:39 robert-KJ379AA-ABA-a6400f gnome-session[15215]: WARNING: App 'compiz.desktop' respawning too quickly
Jan 31 11:39:40 robert-KJ379AA-ABA-a6400f gnome-session[15215]: CRITICAL: We failed, but the fail whale is dead. Sorry....``

ОБНОВЛЕНИЕ 2: Я вижу, что те же сообщения об ошибках происходят каждый раз. Что-то, кажется, уничтожает compiz.desktop/gnome-session. Я просто не знаю, что делать с этим.

ОБНОВИТЕ 3, По-видимому, проблема стала более серьезной. Единица не загружается, и все, что я получаю, пустой рабочий стол. Я пробую шаги поиска и устранения неисправностей на этом потоке без успеха до сих пор. Я сделал вывод, что проблема находится, прежде всего, на стороне программного обеспечения/ОС, а не аппаратной стороне, хотя я действительно не знаю наверняка! Единица не загружается, никакое Средство запуска, никакой Тире не появляется

2
задан 13 April 2017 в 15:23

1 ответ

Можно использовать анализ журнала и программное обеспечение визуализации. Одним из них является Splunk Enterprise, которая в свободном доступе также для персонального использования (анализ данных приблизительно на 500 МБ). В моем случае я раньше изучал/var/log каталоги рекурсивным способом. Попробуйте его Splunk

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

, легко работать с Splunk OOTB, хотя это интересно установить ЛОСЯ. Надежда это помогает.

0
ответ дан 2 December 2019 в 23:23

Другие вопросы по тегам:

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