Периодически зависает mate-settings-daemon (грузит процессор на 100%) [Решено]

[CoolAller]

Приветствую всех!

Собственно проблема следующая, имеется DE MATE 1.8.1, периодически зависает демон mate-settings-daemon, грузит процессор под 100%, постоянно свопает винт и идет дикий жор памяти, случается это не часто, но как правило в самый неподходящий момент. Данная проблема проявляется на разном железе, с проприетарными и свободными драйверами, в том числе и на ноутбуках с процессорами с интегрированным видео ядром. От разрядности OS это не зависит, проблема проявляется рандомно, специально воспроизвести ее не получается. Гугл подсказывает, что точно такая же проблема имеется и с gnome-settings-daemon, чьим форком и является mate-settings-daemon.

Предположительно может помочь следующее (если кому поможет, просьба отписаться):

Ставим dconf-tools: sudo apt-get install dconf-tools
Запускаем dconf-editor, в редакторе идем в ветку org->gnome->settings-daemon->peripherals->keyboard, снимаем галочку remember-numlock-state

Фикс с загрузкой процессора и мигающим NumLock описан здесь, но у меня такой проблемы нет.

На форуме mate-desktop.org пишут, что проблема может быть связана с рандомной сменой прав и владельца каталога в домашней директории пользователя. На всякий случай, если там удалят, вот цитата с форума:

Открыть содержимое (спойлер)

I observed this today for no foreseeable reason on a Mint 17.1 install. Doing an strace on the pid showed it stuck in a tight loop trying to access ~/.cache/dconf/user with a Permission Denied. Checked on the file. It was owned by root instead of my user; I have no idea how that happened. did a chown -R me.me ~/.cache and a pkill -9 -f mate-settings-daemon. Now it works like a charm.

[свернуть]

Так же есть упоминание о утечке памяти здесь. Но лично у меня все нормально с правами, так же это было до использования мной systemd, то есть вопреки некоторым заявлениям он здесь не при чем. У кого проблема с правами пробуем это:

Открыть содержимое (спойлер)

a) kill -9 mate-setting-daemon
b) sudo chown myself:myself /run/user/1000/dconf/user or sudo rm /run/user/1000/dconf/user
c) optionally remove .xsession-errors
d) kill -9 mate-setting-daemon again, to restore sanity after above.

Баг описан здесь и здесь и во многих выдачах гугла.

[свернуть]

Нужно сделать трассировку по PID и просмотреть куда обращается mate-setting-daemon во время зависания, возможно это поможет установить причину проблемы, ниже описано как это сделать, если у кого-то зависнет, выложите пожалуйста вывод трассировки.

Открыть содержимое (спойлер)

Код Выделить Развернуть

sudo aptitude install strace
strace -f $(pidof mate-settings-daemon | sed 's/\([0-9]*\)/\-p \1/g') -o /путь/к/файлу_вывода/output

[свернуть]

Окончательное решение проблемы описано в теме ниже.

Tags: mate-settings-daemon 100% CPU usage, mate-settings-daemon memory leak.

[CoolAller]

Опять словил все тот же глюк, но теперь хоть более-менее понятно когда он появляется. Самое интересное, что действительно mate-settings-daemon не может получить доступ к файлу /run/user/1000/dconf/user не смотря на то, что права имеются.
Вот полученный вывод:

Открыть содержимое (спойлер)

6240  recvmsg(3, 0x7ffda79f9640, 0)     = -1 EAGAIN (Resource temporarily unavailable)
6240  recvmsg(3, 0x7ffda79f9640, 0)     = -1 EAGAIN (Resource temporarily unavailable)
6240  munmap(0x7f87d53b6000, 21236)     = 0
6240  access("/run", F_OK)              = 0
6240  stat("/run", {st_mode=S_IFDIR|0755, st_size=860, ...}) = 0
6240  access("/run/user", F_OK)         = 0
6240  stat("/run/user", {st_mode=S_IFDIR|0755, st_size=80, ...}) = 0
6240  access("/run/user/1000", F_OK)    = 0
6240  stat("/run/user/1000", {st_mode=S_IFDIR|0700, st_size=140, ...}) = 0
6240  access("/run/user/1000/dconf", F_OK) = 0
6240  stat("/run/user/1000/dconf", {st_mode=S_IFDIR|0700, st_size=60, ...}) = 0
6240  open("/run/user/1000/dconf/user", O_RDWR|O_CREAT, 0600) = -1 EACCES (Permission denied)
6240  write(2, "\n(mate-settings-daemon:6240): dc"..., 150) = 150
6240  close(-1)                         = -1 EBADF (Bad file descriptor)
6240  open("/home/coolaller/.config/dconf/user", O_RDONLY) = 16
6240  fstat(16, {st_mode=S_IFREG|0644, st_size=21236, ...}) = 0
6240  mmap(NULL, 21236, PROT_READ, MAP_PRIVATE, 16, 0) = 0x7f87d53b6000
6240  close(16)                         = 0
6240  poll([{fd=3, events=POLLIN|POLLOUT}], 1, 4294967295) = 1 ([{fd=3, revents=POLLOUT}])
6240  writev(3, [{"\203\2\1\0", 4}, {NULL, 0}, {"", 0}], 3) = 4
6240  poll([{fd=3, events=POLLIN}], 1, 4294967295) = 1 ([{fd=3, revents=POLLIN}])
6240  recvmsg(3, {msg_name(0)=NULL, msg_iov(1)=[{"\1\2\353+\200\0\0\0\n\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096}], msg_controllen=0, msg_flags=0}, 0) = 544

[свернуть]

На GitHub утверждают, что виновника нужно пинать на bugzilla.redhat.com. Попробую обновить systemd, посмотрим что будет дальше.

[VKH]

Если вопрос решил, поделись решением для будущих поколений.

[CoolAller]

VKH, я не могу сказать, что проблема решена, официально проблему не признали, хотя она и тянется уже несколько лет, а точнее судя по дате в багзилле с 11-11-2011 и о ней пишут везде где только можно. На одной машине я обновил systemd до последней на сегодняшний день версии 215-17+deb8u2 в репозитории Jessie, пока проблема не повторялась, но это не значит, что ее нет, на другой машине с версией 227-2 из Testing/Stretch я получил все тот же косяк, причем практически сразу. В треде разработчиков mate-setting-daemon на GitHub ответили, что проблема связана с systemd. Можно попробовать откатиться на sysvinit, установив: sysvinit-core sysvinit sysvinit-utils systemd-shim, правда полностью избавится от systemd все равно не получится. Похоже Debian скоро таки падет стараниями Поттеринга и придется переезжать на другой дистр) Одно можно сказать точно проблема с dconf (/run/user/1000/dconf/user Permission denied) после возникновения которой происходит зависание mate-setting-daemon действительно существует и она проигнорирована. Пишете репорты в баг-трекер Debian (ссылка на баг приведена выше) и на bugzilla.redhat.com, так как главный деятель виновный в появлении systemd находится там. Если данный глюк будет появляться и с sysvinit, тогда пишите на GitHub, там хотя бы есть шанс, что хоть что-то ответят, ну или просто посочувствуют).

[CoolAller]

В продолжение темы,  mate-settings-daemon глючит и с systemd 215-17+deb8u2, все по той же причине, устновка systemd-shim не помогает.

[CoolAller]

Если я что-то понимаю, то разработчики Linux Mint решили сами пофиксить этот баг, похоже их это тоже достало.

Как добиться этого от ментейнеров Debian неизвестно, хоть в пору пакеты из LMDE выкачивать или Betsy ставить

[Yrii]

Как добиться этого от ментейнеров Debian неизвестно, хоть в пору пакеты из LMDE выкачивать или Betsy ставить

Ну, зачем же так. Скачай исходный код нужного пакета и наложи патч (или просто в исходниках руками поменяй), собери обратно.

[VKH]

У меня на ноуте проблемка с зависанием пропала как только отказался от свопа и чутка похимичил в proc/sys/vm.

[CoolAller]

похимичил в proc/sys/vm

Думаю, что к зависанию mate-setting-daemon это врядли относится, но все же хотелось бы подробностей.

Cообщение объединено 14 января 2016, 16:38:15
Yrii, да все руки никак не дойдут, сейчас времени совсем нет, вот если бы кто-нибудь собрал бы...   

[VKH]

похимичил в proc/sys/vm

Думаю, что к зависанию mate-setting-daemon это врядли относится, но все же хотелось бы подробностей.

Обратил внимание что mate-setting-daemon обычно нагружает сильно проц когда система начинает использовать своп. Перезапуск иксов проблему не решал и проц был нагружен, только перезагрузка. Экспериментировал с данными переменными vm.swappiness, vm.dirty_background_ratio, vm.dirty_ratio и vm.dirty_writeback_centisecs. Зависания стали реже. После этого отключил своп. Зависаний не наблюдаю в течении двух месяцев. В чем была проблема с нагрузкой на проц в логах особо не разбирался, но это происходило при обращении к user 1000 (что то вроде этого).

[CoolAller]

это происходило при обращении к user 1000

Об этом и речь в моих постах выше, своп не являлся причиной, просто с ним этот косяк вылазил чаще, поюзайте какие-либо программы через sudo и снова его получите, решение предложили разработчики LMDE, сейчас взял их пакеты с systemd, правда там другая версия, пришлось править, но с ними больше не виснет, нужно собрать свои deb пакеты, вот только если бы кто помог, там править нужно в исходном коде и потом компилить, в готовом deb пакете из реп это не исправишь, люди говорят, что его уже даже в Red Hat исправили. Пробовал запускать ./configure, но он плюется ошибками, типа того ему не хватает, этого и т.д.

[CoolAller]

После довольно продолжительного тестирования на разных машинах можно сказать, что проблема больше не проявлялась, так что она таки решается путем правки systemd.

Вот патченные пакеты systemd (Debian Jessie):
systemd_215-17+deb8u8_amd64
systemd_215-17+deb8u8_i386

[allexnew]

Вот патченные пакеты systemd (Debian Jessie):

Бро, спасибо!  Достал уже этот mate-settings-daemon. Раньше на ноуте только было на Celerone сейчас и на рабочем компе та же ерунда.

[muslimgauze]

Вот патченные пакеты systemd (Debian Jessie): systemd_215-17+deb8u3_amd64 и systemd_215-17+deb8u3_i386

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

[vovan--vovan]

наткнулся на пароль в архиве

Да нет тут ни какого пароля. Все скачалось и распаковалось. Пишите в личку куда залить папки, сожму в один архив (или без него) и залью. Благодарить не надо.