mate-settings-daemon - apparent memory leak

[Monsta]

Just in case - did you install all the updates? Especially systemd and libsystemd-*, their version should be 204-5linuxmint1.

[chritcu]

Yes, I have installed all updates and systemd and libsystemd-* have version 204-5linuxmint1.

[Monsta]

That doesn't sound good. That systemd update was meant to solve exactly this problem - wrong permissions for /run/user which cause various apps (not only mate-settings-daemon) to use 100% CPU or crash. Now it looks like it's not solved...

[Hansl]

Same here — systemd and libsystemd-* are 204-5linuxmint1.
As a bandaid solution I wrote a simple script ~/bin/fix-dconf-user:

Code: Select all

#!/bin/sh
sudo chown <my name>:<my group> /run/user/1000/dconf/user 

When I notice such trouble then I a) run that script and b) kill the offending mint-?? process which will then restart and work correctly… for some time…

[chritcu]

Here is my attempt to write a better workaround script. You need to have the "inotify-tools" package for this to work.

Code: Select all

sudo apt-get install inotify-tools

All you need to do is run this as root and pass your user name as argument. For instance:

Code: Select all

sudo ./fix-permissions.sh hritcu

It will detect for itself when the permissions are scrued up and fix them automatically and kill settings-daemon.

Code: Select all

#!/bin/bash

if [ "$#" -ne 1 ]
then
    echo "Please pass user name as argument"
    exit 1
fi

USER_ID=`id -u "$1"`
DIR="/run/user/$USER_ID/dconf"
FILE="$DIR/user"

echo "Monitoring $FILE"

while true
do
    if [ -f "$FILE" ] && [ $(stat -c %U "$FILE") != "$1" ]
    then
        echo "Fixing bad permissions"
        chown "$1":"$1" "$FILE"
        echo "Killing mate-settings-daemon"
        killall mate-settings-daemon
    else
        echo "Nothing to do"
    fi
    echo "Going to sleep"
    inotifywait -q -r -e attrib -e create "$DIR"
done

From what I can tell it works well, but there is still some chance of race conditions lurking around.

[Monsta]

According to Clem, the new workaround for this issue is to remove systemd and libpam-systemd packages. Of course, you can remove systemd only if you don't use it as the init system.

[chritcu]

Noob question: How can I find out whether I use systemd as the init system or not? I'm using an untweaked LMDE 201403 release.

[Monsta]

If you didn't set it up manually, you don't use it.

[chritcu]

I can confirm that removing these two packages and restarting the system seems to solve the bad rights problem. So far I didn't even manage to get /run/user/1000/dconf to get created at all, even less to have it get bad rights.

[Monsta]

Right, I don't even have /run/user directory on the machine where libpam-systemd was never installed.

How does mate-settings-daemon behave now?

[chritcu]

No problem with mate-settings-daemon since removing the packages. I'll keep an eye on it in the next few days and let you know.

[martywd]

A week or so ago, I did the full manual LMDE 201403 MATE 64-bit install (manually mounted /dev/sdaX /target, chroot to '/target', manually configured /etc/fstab, etc.) Haven't had any major issues since the updated 'systemd' packages came available for install.

But noticed above that removing systemd packages would eliminate the creation of '/run/user/...' I figured I'd give this a try?

I was able to removed the following packages:

libpam-systemd:amd64 ------ 204-5linuxmint1
libsystemd-daemon0:amd64 ------- 204-5linuxmint1
libsystemd-journal0:amd64 ------- 204-5linuxmint1
systemd:amd64 ------ 204-5linuxmint1

Still have the 'libsystemd-login0' package installed since aptitude insists that approx. 90 other packages would be removed as well. Some which if removed would definitely render this machine unbootable.

No issues on reboot, and now no '/run/user/...' directory. I'll continue the monitor memory and swap usage.
.

[chritcu]

No memory leak in mate-settings-daemon since removing those packages. It stays between 10 and 20MiB.

[Hansl]

Well, for the moment this means to stay with sysvinit and not to toy with systemd.
But since it would be nice to have the fast start of systemd, please inform us when there are further developments getting mint-?? stable with systemd.

Thanks! Hans

[ddurdle]

which login manager are you guys using?

After encountering this issue too many times on my systems, I decided to uninstall systemd, but it takes with it gdm3. I installed mdm, but I get an error on bootup about Mint X being missing. I'm still able to log in.

[Hansl]

On this netbook here I have gdm3 and marco running. Don't know or understand why both.
On this netbook here I kept the half systemd install from the Mint updates, is now version 204-6 — had just now again mate-panel hung at 100% cpu. But on this machine, this happens only seldom.

[unprinted]

I've reported the Mint Software Manager issue here:
https://github.com/linuxmint/mintinstall/issues/52

I can confirm that on a new install of LMDE 201403, all upgrades done, problems with this followed starting MSM.

I'd also tried killing the task, before reading this, but as has been said, it happily respawns.

[chritcu]

Removing systemd as martywd suggested solved this problem for me.

[nevart1]

Well it is not a perfect solution, but I was able to stop the CPU hijack problem by not killing the process. Instead, merely stop it by right-clicking the process and selecting stop. Really that's all you need to do apart from occasionally keeping an eye on it.