Элементарная ОС зависает случайным образом

1402
Agterbosch

Я работаю с Elementary OS Freya уже давно, такая же установка не менее 2 лет, и время от времени она просто зависает полностью, больше не отвечает, не только рабочий стол, но и полностью, единственный способ исправить это - удерживать кнопку питания.
Сначала у меня была проблема со свопом, но я все исправил, и я также установил проприетарные драйверы nvidia, но ни одна из этих вещей, похоже, не устранила ее.

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

Кроме того, это, кажется, происходит совершенно случайно

 Aug 21 13:15:34 Asus colord: Automatic metadata add icc-dc945c3592fc6c2089fd79db35a300dc to xrandr-LVDS1 Aug 21 13:15:34 Asus colord: Profile added: icc-dc945c3592fc6c2089fd79db35a300dc Aug 21 13:15:34 Asus kernel: [ 42.656869] audit_printk_skb: 48 callbacks suppressed Aug 21 13:15:34 Asus kernel: [ 42.656874] audit: type=1400 audit(1503314134.828:28): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="/usr/lib/cups/backend/cups-pdf" pid=2314 comm="apparmor_parser" Aug 21 13:15:34 Asus kernel: [ 42.656883] audit: type=1400 audit(1503314134.828:29): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="/usr/sbin/cupsd" pid=2314 comm="apparmor_parser" Aug 21 13:15:34 Asus colord: Profile added: M2020-Series-Gray.. Aug 21 13:15:34 Asus colord: Device added: cups-M2020-Series Aug 21 13:15:35 Asus dbus[457]: [system] Activating service name='org.freedesktop.UDisks2' (using servicehelper) Aug 21 13:15:35 Asus udisksd[2385]: udisks daemon version 2.1.3 starting Aug 21 13:15:35 Asus dbus[457]: [system] Successfully activated service 'org.freedesktop.UDisks2' Aug 21 13:15:35 Asus udisksd[2385]: Acquired the name org.freedesktop.UDisks2 on the system message bus Aug 21 13:15:39 Asus kernel: [ 46.979071] ACPI Warning: \_SB_.PCI0.PEG0.GFX0._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20150930/nsarguments-95) Aug 21 13:15:39 Asus kernel: [ 46.979166] ACPI Warning: \_SB_.PCI0.PEG0.GFX0._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20150930/nsarguments-95) Aug 21 13:15:39 Asus kernel: [ 46.979239] nouveau 0000:01:00.0: DRM: suspending console... Aug 21 13:15:39 Asus kernel: [ 46.979243] nouveau 0000:01:00.0: DRM: suspending display... Aug 21 13:15:39 Asus kernel: [ 46.979254] nouveau 0000:01:00.0: DRM: evicting buffers... Aug 21 13:15:39 Asus kernel: [ 46.979256] nouveau 0000:01:00.0: DRM: waiting for kernel channels to go idle... Aug 21 13:15:39 Asus kernel: [ 46.979297] nouveau 0000:01:00.0: DRM: suspending client object trees... Aug 21 13:15:39 Asus kernel: [ 46.979533] nouveau 0000:01:00.0: DRM: suspending kernel object tree... Aug 21 13:16:12 Asus wpa_supplicant[1005]: wlan0: CTRL-EVENT-SCAN-STARTED  Aug 21 13:16:13 Asus sm-mta[1873]: unable to qualify my own domain name (Asus) -- using short name Aug 21 13:16:13 Asus sm-mta[1873]: gethostbyaddr(192.168.0.103) failed: 1 Aug 21 13:16:13 Asus sm-mta[2633]: starting daemon (8.14.4): SMTP+queueing@00:10:00 Aug 21 13:16:15 Asus sm-msp-queue[1882]: unable to qualify my own domain name (Asus) -- using short name Aug 21 13:16:16 Asus kernel: [ 84.366042] init: plymouth-stop pre-start process (2771) terminated with status 1 
0
Случалось ли замерзать время от времени в течение 2 лет? Какие-нибудь обновления, особенно ядра, до его запуска? По поводу журнала, он зависал сразу после 13:16:16 или около того, через 84 секунды после загрузки? Это может быть просто журнал текущей сессии, предыдущий может быть где-то еще (в / var / log /?), Может иметь панику ядра или что-то похожее на <2839824> с некоторыми символами `?`, Определенно выделяется в dmesg / системный журнал. Или он мог замерзнуть "твердым" без сообщений тоже Xen2050 7 лет назад 0
Да, у меня всегда была эта проблема с самого начала, но никаких других проблем. Это из / var / log / syslog, кстати .. Я скопировал его из журнала после перезагрузки ноутбука, так что я могу только догадываться, что он завис в 13:15:39 .. Но даже если он замерз так) разве не случилось бы что-то плохое прямо перед этим? Если это не аппаратная проблема, но у меня никогда не было этой проблемы на Debian, который он запускал до элементарной Agterbosch 7 лет назад 0
Я уверен, что часть `[46.979256]` - это секунды, прошедшие с момента загрузки, которые пишет dmesg (или ядро?). Я обычно работаю вживую, поэтому, когда происходит редкий сбой (ежегодно), я не могу проверить логи (были в оперативной памяти, стерли при перезагрузке). Иногда просто прямо к панике msgs, но резкое замораживание даже не показывает те. Старые журналы еще могут быть где-то там ... Я просто догадываюсь, но, поскольку с Debian все было в порядке, может быть, это проблема с ядром сейчас? Можно попробовать загрузиться с другим ядром (более новым или старым, может быть, «стабильным»?), Но сначала поискать, как загрузить * предыдущее / старое ядро ​​*, на всякий случай. Xen2050 7 лет назад 0
На самом деле, старый компьютер чаще зависал, когда я использовал compiz, я думаю, что в элементарной ОС есть хорошие окна и графика, поэтому, возможно, попробуйте отключить аппаратное ускорение или отключить некоторые графические эффекты (композитинг)? Более простой оконный менеджер - тоже идея Xen2050 7 лет назад 0
Я не знаю, я сейчас работаю на последнем ядре, но у меня эта проблема была 2 года на каждом выпущенном ядре. Что касается аппаратного обеспечения, я использую i5 третьего поколения с 6 Гб оперативной памяти, Geforce GT540M CUDA 1 ГБ, и SSD, который до сих пор наполовину полон. Кроме того, он никогда не оказывается под нагрузкой во время замерзания Agterbosch 7 лет назад 0
Похоже, нет сообщений о зависании ... если бы ядро ​​все еще было "живым", я бы надеялся, что оно напечатало бы что-нибудь, и вы все равно могли бы использовать клавиши "Magic SysRq" для синхронизации и перезагрузки с клавиатурой (возможно, придется включить их). Поскольку вы обновляли ядро ​​все время, это, вероятно, не легко исправляемая ошибка. Я не слишком уверен, что делать, попробуйте отключить какие-либо аппаратные драйверы (видео кажется особенно уязвимым), или наоборот, попытаться найти некоторые, если их нет, или использовать дистрибутив, который не зависает, и установить некоторые пакеты ElementaryOS и посмотреть, если они работать нормально? Xen2050 7 лет назад 0
О каких магических ключах ты говоришь? Я уже переключился на другие драйверы графического процессора после прочтения, что у некоторых людей были проблемы с nvidia, но это не помогло мне. Во всяком случае, странным в этом также является то, что он не зависает при загрузке графического процессора, но просто случайно, как сейчас, он завис, пока у меня не было ничего открытого, кроме Leafpad .. Также я не могу найти никого другого, имеющего эту проблему с eOS, что заставляет меня думать, что это либо ssd, ram, либо cpu, хотя факт, что debian работает нормально 2 года назад, возможно, это было совпадением, я мог бы попробовать другой дистрибутив и протестировать оперативную память и процессор Agterbosch 7 лет назад 0
В Википедии есть хороший обзор https://en.wikipedia.org/wiki/Magic_SysRq_key. Это может быть аппаратная проблема, определенно тестовый баран, может искать вентиляционные отверстия, блокирующие ворс, или вентиляторы, которые вышли из строя. Контролируйте температуры (с помощью `датчиков`), если можете. По крайней мере, если вы попробуете некоторые другие искажения вживую (с помощью USB или DVD), тоже следует оставить ваш «основной» диск, иначе многие iso будут загружаться из grub, если вы скопируете их и добавите правильную запись. Xen2050 7 лет назад 0
Спасибо, мужик, я никогда не знал, что это такое, в следующий раз, когда это случится, я попробую, если только я смогу предсказать, когда это произойдет, поскольку это происходит не каждый день, и это кажется совершенно случайным. Кроме того, в большинстве случаев тепло кажется хорошим, я только что применил термопасту около 6 месяцев назад. Agterbosch 7 лет назад 0
попробуйте спросить на https://elementaryos.stackexchange.com/ phuclv 6 лет назад 0

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

0
Felipe Butcher

Это не имеет особого смысла, но удаление wingpanel-indicator-powerрешило проблемы с зависанием для меня.

sudo apt-get remove wingpanel-indicator-power 

Моя система не зависала полностью, как вы сообщали, но у меня были быстрые зависания, например, при открытии новой вкладки в Chrome.

0
baelx

Действительно трудно дать серебряный ответ на такой вопрос, потому что он настолько широк, но теоретически вы можете получить его, пройдя через слои вашей системы (ознакомьтесь с этим подробным описанием дистрибутива eOS ) до ядра, чтобы посмотрим, что именно вызывает проблему. Считайте, что это ответ, чтобы помочь вам прийти к более точному вопросу. В процессе вы, вероятно, узнаете много нового о том, как работает ваша система.

Для начала, в следующий раз, когда он зависает, попробуйте переключиться на tty . Это делается с помощью нажатия клавиши ( CTRL + ALT + F1 through F6. Если ваши функциональные клавиши обычно используются для регулировки громкости, яркости и т. Д., Возможно, вам придется включить Fnклавишу в эти комбинации. Если это удастся, я начну подозревать некоторую часть вашего графического интерфейса. После переключения введите свои учетные данные пользователя, а затем вы можете попробовать множество методов для диагностики источника проблемы. Пара может быть:

  • Запустите topкоманду и найдите процесс (в верхней части списка), который потребляет 100% ресурсов ЦП или большое количество любых других ресурсов.
  • Проверьте различные слои журналов. Если вы подозреваете проблему с графическим интерфейсом, начните с журналов Xorg, которые являются самым низким уровнем «GUI», то есть вашим рабочим столом. Попробуйте проверить, регистрирует ли X-сервер какие-либо события, например. Направления Arch Wiki по этому вопросу довольно хороши. А именно, попробуйте проверить Xorg.0.log и Xorg.1.log на наличие строк, начинающихся с EEили WWуказывающих на ошибки или предупреждения соответственно.

Чтобы вернуться к графическому интерфейсу, нажмите Ctrl + Alt + F7(опять же, Fnключ может применяться здесь).