memory usage

[brizou]

I have mate 1.6 on my archlinux install. mate-settings-daemon is using a lot of ram after a while, I just rebooted after three days, mate-daemon-settings was using 4.7Go of ram. I assume it's a memory leak but have now idea where the problem is

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/3035054-memory-usage?utm_campaign=plugin&utm_content=tracker%2F867277&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F867277&utm_medium=issues&utm_source=github).

[CoolAller]

@linas, Here is my ticket to the Debian bug tracker: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=824950 The bug is still present, at least in latest version of the systemd in the official repository of Debian 8 Jessie. But I rebuild the package systemd with the LMDE maintainer's patch and the problem no longer appeared. Maybe the solution proposed by the developers of LMDE is not quite true, but in any case it works. I don't know how to convince support of Debian to fix this bug. Perhaps you will do it better than me.

[linas]

Aiiee: there are a dozen debian bugs: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=732209 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=766464 and more: 767173, 769889, 772910, 807878, 818600, 818601, 824950

[linas]

Ahh. This post: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=732209#258 implies that the root of the problem is that "su" is leaking user environment variables into the root shell, where they get mis-used, and cause trouble, such as this. This seems like a plausible argument to me: i.e. at the core, its "su" that needs to be fixed.

[CoolAller]

@linas, The quantity does not mean that someone will fix this bug.))

[CoolAller]

The far future - 2068 year. The earth is enslaved terminators... and this bug is still present)) Bug tracker status - Not a bug, it is feature) won't fix))

[monsta]

it is also claimed that https://cgit.freedesktop.org/systemd/systemd/commit/?id=baae0358f349870544884e405e82e4be7d8add9f fixes the bug

No, it doesn't. It's an earlier patch, and it indeed fixed some issue (which I don't remember now, too much time passed). But it doesn't prevent the permission issue on /run/user/1000/dconf/user.

[monsta]

The far future - 2068 year. The earth is enslaved terminators... and this bug is still present))

Assuming that terminators would have Linux-based firmware, the bug should prevent them from taking over the Earth (well, unless they'd run on Gentoo or Devuan or Slackware)... :laughing:

[sbalneav]

Since this bug is marked "wontfix" in pam_systemd, I've come up with the following:

https://github.com/sbalneav/libpam-envclean

This fixes the problem, insofar as it cleans up the XDG_RUNTIME_DIR variable if the authenticating user is different from the user of the runtime directory on the disk.

This is gross as heck, but I see no other way to address this issue, given the unwillingness of other upstreams to address the issue.

Thoughts on this being part of MATE?

[usmarine2141]

Should be! Thank you for that!!! good work

On Wed, Sep 14, 2016 at 3:45 PM, Scott Balneaves notifications@github.com wrote:

Since this bug is marked "wontfix" in pam_systemd, I've come up with the following:

https://github.com/sbalneav/libpam-envclean

This fixes the problem, insofar as it cleans up the XDG_RUNTIME_DIR variable if the authenticating user is different from the user of the runtime directory on the disk.

This is gross as heck, but I see no other way to address this issue, given the unwillingness of other upstreams to address the issue.

Thoughts on this being part of MATE?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/mate-desktop/mate-settings-daemon/issues/44#issuecomment-247147445, or mute the thread https://github.com/notifications/unsubscribe-auth/ATwSo7ou8y1mRQrQ9c-QbNCp-zm8zr7Pks5qqFzQgaJpZM4Am_JY .

[roschacker]

the same problem still actual on fresh installation: CPU and memory leak, freezes, ...

Early mentioned errors are present in ~/.xsession-errors

my config:

➜ ~inxi -F

System: Host: Kabini Kernel: 4.4.0-53-generic x86_64 (64 bit) Desktop: MATE 1.16.1 Distro: Linux Mint 18.1 Serena Machine: Mobo: ASRock model: QC5000M Bios: American Megatrends v: P1.00 date: 05/07/2015 CPU: Quad core AMD A4-5000 APU with Radeon HD Graphics (-MCP-) cache: 8192 KB clock speeds: max: 1500 MHz 1: 800 MHz 2: 800 MHz 3: 1100 MHz 4: 800 MHz Graphics: Card: Advanced Micro Devices [AMD/ATI] Kabini [Radeon HD 8330] Display Server: X.Org 1.18.4 drivers: ati,radeon (unloaded: fbdev,vesa) Resolution: 1980x1080@60.00hz GLX Renderer: Gallium 0.4 on AMD KABINI (DRM 2.43.0, LLVM 3.8.0) GLX Version: 3.0 Mesa 11.2.0 Audio: Card-1 Advanced Micro Devices [AMD] FCH Azalia Controller driver: snd_hda_intel Card-2 Advanced Micro Devices [AMD/ATI] Kabini HDMI/DP Audio driver: snd_hda_intel Sound: Advanced Linux Sound Architecture v: k4.4.0-53-generic Network: Card-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller driver: r8169 IF: enp3s0 state: up speed: 1000 Mbps duplex: full mac: d0:50:99:a8:a0:62 Card-2: Broadcom BCM4360 802.11ac Wireless Network Adapter driver: bcma-pci-bridge IF: N/A state: N/A mac: N/A Drives: HDD Total Size: 240.1GB (6.1% used) ID-1: /dev/sda model: ADATA_SP550 size: 240.1GB Partition: ID-1: / size: 213G used: 6.6G (4%) fs: ext4 dev: /dev/dm-0 ID-2: /boot size: 472M used: 111M (25%) fs: ext2 dev: /dev/sda1 ID-3: swap-1 size: 7.99GB used: 0.08GB (1%) fs: swap dev: /dev/dm-1 RAID: No RAID devices: /proc/mdstat, md_mod kernel module present Sensors: System Temperatures: cpu: 56.9C mobo: N/A gpu: 57.0 Fan Speeds (in rpm): cpu: N/A Info: Processes: 221 Uptime: 2:21 Memory: 809.9/7417.2MB Client: Shell (zsh) inxi: 2.2.35

temporary fixed with 'workaround' sudo rm /run/user/1000/dconf/user

from https://github.com/mate-desktop/mate-settings-daemon/issues/44#issuecomment-106911137

[CoolAller]

I confirm, this FIX Clean XDG_RUNTIME_DIR does not work. The only thing that really helps to get rid of hangs and memory leak: https://github.com/linuxmint/systemd-betsy/commit/f7ab85f1e1169ac1598dfc1fba1c01063840b3c5 PS. I'm already sick of recompiling Systemd packages. Maintainers do not pay any attention to user complaints.

[mootensai]

I'm using Parrot OS with MATE 1.16.1 and its still happening.. suddenly my RAM is full & my mouse is stuttering..

[jggouvea]

This bug hit me today after a fresh and clean install of Arch Linux. 100% CPU and 100% RAM used all the time. Escalating quickly: from 1% CPU and RAM to 100% in less than 4 minutes. Binaries involved were mate-settings-daemon and mate-panel. Following the instructions provided here (that thing about /run/user) I was able to get the system working again (after three or four Xorg restarts). Judging from what you have written, the culprit was my using of pluma as sudo to edit /etc/fstab.

So, in case anyone needs any more confirmation. I give my testimony.

[mariusrodi]

Have the same problem on Parrot OS 3.7 and MATE 1.16.2 after a clean and fresh install. In less then a minute from 1% to 100% RAM. Two minutes in and Swap was flooded too. Happened when I wanted to start the appearance preferences menu. The appearance menu was then hovering on the desktop but frozen and transparent. mate-settings-deamon was the process with the most RAM consumption by far.

[dmknght]

HI all. I am using Parrot OS 3.8 and i am having this issue (from 9-9-2017 actually). Big thank to sir linas you saved my asses. I though it came from latest update but other users confirmed here that they had it before i had. I think if we create a bash file in /usr/bin/ 'rm /run/user/1000/dconf/user killall -9 mate-settings-daemon' and quickly run this as root maybe help. Back to my machine, I found dozen process syncdaemon. I think it was created by mate-settings-daemon. Each process used 0% CPU and 33MB Ram, but killall them saved 30% CPU for me. Hope this information helpful for you guys.

[gentoo90]

This still happens with mate-settings-daemon 1.18.1 on Gentoo Linux. But it doesn't eat memory if launched without the keyboard plugin.

[monsta]

Well that's something new. As it's Gentoo, I guess you don't have libpam-systemd or any other systemd components?

[gentoo90]

@monsta, no I don't. I use openrc-0.34.11.

[monsta]

Yeah, so it means it's not caused by that old gksu/libpam-systemd conflict. Can you check which part of the plugin eats memory (for example, with valgrind)?

[gentoo90]

I've tried debugging and it looks like keyboard is spamming with tons of change events and calling plugins/keyboard/msd-keyboard-manager.c:apply_settings() and plugins/keyboard/msd-keyboard-xkb.c:apply_desktop_settings() over and over again.

I have no experience with valgrind. What command should I launch to get something useful?

[monsta]

I'm not expert with it, but usually just running valgrind with executable as an argument should be enough to show most memleaks. At the end valgrind will also suggest to use some additional options.

If both functions are periodically called, it could be from msd_keyboard_new_device function in msd-keyboard-xkb.c... though I don't see where it could eat a lot of memory.

[lukefromdc]

I've never seen this happen on any version of MATE on Debian Unstable nor on Ubuntu. Wonder what the difference is?

[linas]

@lukefromdc Please see the https://github.com/mate-desktop/mate-settings-daemon/issues/44#issuecomment-61430431 and the comments that follow, and also https://github.com/mate-desktop/mate-settings-daemon/issues/44#issuecomment-106911137

The problem was originally that some MATE app got run as root, and systemd changed ownership permissions on /run/user/1000, resulting in the very rapid memleak. The instructions for how to reproduce this worked easily, last time I tried them. What's new now is that gentoo is experiencing this, without systemd, but I bet that the root cause is the same: running some X11/gtk app as root, and clobbering ownership perms /run/user/<userid> as a result .

[lukefromdc]

Usually if I get that problem, the offender is Caja and it cannot be restarted, thus blocking session start altogether until ~/.cache/dconf/user gets its permissions reset from console or another session. Having the session actually work and just eat a lot of RAM and/or CPU would be a big improvement over this.

[monsta]

Forget about systemd, it's not going to be fixed on their side, and it can be caused only if libpam-systemd is in your system, which shouldn't be in Gentoo.

[nudgegoonies]

I can confirm this problem with debian stretch.

@sbalneav In which file do i have to add he line? It can be found in runuser-l, systemd-user, common-session and in lightdm-greeter.

[nudgegoonies]

With debian Buster i havn't seen this effect anymore. Was it fixed within an other issue?