Странное поведение (рама и время логина)

[AlexYeCu]

Заметил странное поведение системы.
Итак, при некоторых обстоятельствах возможны следующие вещи:
1. Некоторые чувствительные процессы (например, mpd, он вообще это любит делать при малейшем непорядке в системе) становятся зомбями.
2. Первые иксы могут упасть при переключении на них со вторых.
3. После любого из подобных происшествий после использования утилиты su и ввода пароля root-а проходит значительное время, секунд так до 20-и до логина под этим самым root-ом. После перезагрузки проблема пропадает.

Вот с обстоятельствами всё не ясно: под подозрением утечки памяти в кой каком софте (как проприетарном, так и свободном). Вроде бы коррелирует с количеством занятой памяти, но это не точно: проблема с долгим логином не пропадает и после принудительной очистки кэшей. Места на диске для раздела не сказать, чтоб много, но, в общем, хватает, своп на ssd есть, подключён, но практически не используется. Падение первых иксов при переключении вроде бы коррелирует с падением nvidia-settings в корку, вот только постоянно nvidia-settings не включены и не должны ни на что влиять.

Возможно, кого-то натолкнёт на те или иные мысли.

F26.
6700K, 16Gb ram

[Bizdelnick]

Каким образом запускается mpd? Какой у него PPID? Что в логах во время глюков (journalctl, dmesg, в случае su — /var/log/secure)?

[AlexYeCu]

Каким образом запускается mpd? Какой у него PPID?)?

На конкретной машине — hook из xmonad. PPID 1. Но его я для примера привёл, неоднократно сталкивался с тем обстоятельством, что mpd ведёт себя как «шахтёрская канарейка» — валится при малейших проблемах, когда всё остальное работает. Скажем, на той же малине при посыпавшейся sd-карте mpd пал одним из первых. Ну и заметить проблемы с музыкальным плеером, как правило, куда проще, чем с различными демонами.

Что в логах во время глюков (journalctl, dmesg

В journalctl единственный подозрительный момент был — core dump nvidia-settings.
dmesg если поймаю подобное ещё раз гляну.
Хотя вот сейчас глянул — сегфолт nvidia-dettings одна из последних строк. Занятно, в эту загрузку проблем не наблюдалось.

в случае su — /var/log/secure

Нет такого файла. Должен заметить, что вот этот момент с долгим логином мне особенно непонятен и подозрителен.

В общем, посмотрю, какую ещё информацию можно собрать.

[Bizdelnick]

На конкретной машине — hook из xmonad. PPID 1.

Если PPID 1, то единственная причина, по которой он может стать зомби, — глюк systemd. Очень странный глюк.
Я бы на всякий случай прогнал rpm -Va (надеюсь, правильно помню заклинание) и memtest.

[AlexYeCu]

rpm -Va

Проверю.

memtest

Вот тоже под подозрением память, прогонял memtester 1 раз 13 гигов (не захватил то, что было занято и полгига свободных), ошибок не выявил. Позже нормально прогоню. Вот думаю, не может ли это проявляться чудесная работа с памятью Skylake-а или чудный hyperthreading оного.

[Bizdelnick]

прогонял memtester 1 раз 13 гигов

1 раз (все проходы) или 1 проход? 1 проход — это вообще ни о чём. Бывает, и все проходы с первого раза ошибку не находят, а на n-й вылезает.

[AlexYeCu]

Дополнительные подробности.
Баг с долгим логином как-то связан с lxdm: он не проявляется в чистой консоли и пропадает после перезапуска lxdm.
Т. е. скорее всего при переключении валятся не иксы, а именно lxdm.
А вот в консоли при этом слетает локаль, что указывает уже на видеодрайвер.

[anonymous.ru]

dbus падает?

[AlexYeCu]

dbus падает?

Хм, а вот это не проверял. Проверю.