New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

memory usage #44

Open
brizou opened this Issue Apr 25, 2013 · 76 comments

Comments

Projects
None yet
@brizou

brizou commented Apr 25, 2013

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).
@sbalneav

This comment has been minimized.

Show comment
Hide comment
@sbalneav

sbalneav May 9, 2013

Has this problem re-ocurred for you?

sbalneav commented May 9, 2013

Has this problem re-ocurred for you?

@brizou

This comment has been minimized.

Show comment
Hide comment
@brizou

brizou May 9, 2013

yes all the time, after a day or two, mate-settings-daemon is using a lot of ram and I have to reboot

brizou commented May 9, 2013

yes all the time, after a day or two, mate-settings-daemon is using a lot of ram and I have to reboot

@sbalneav

This comment has been minimized.

Show comment
Hide comment
@sbalneav

sbalneav May 13, 2013

Can you provide a little more information? I haven't got a lot to go on here. What apps are you running? Can you play around and see if running a specific app does it? Are you running a background slideshow? Any messages in ~/.xsession-errors?

Sorry, but I'm just not seeing that behaviour here.

sbalneav commented May 13, 2013

Can you provide a little more information? I haven't got a lot to go on here. What apps are you running? Can you play around and see if running a specific app does it? Are you running a background slideshow? Any messages in ~/.xsession-errors?

Sorry, but I'm just not seeing that behaviour here.

@brizou

This comment has been minimized.

Show comment
Hide comment
@brizou

brizou May 15, 2013

Just saw your reply, I just rebooted. I will keep you posted if this happens again in the next couple of days. I think there wil be a mate update though

brizou commented May 15, 2013

Just saw your reply, I just rebooted. I will keep you posted if this happens again in the next couple of days. I think there wil be a mate update though

@brizou

This comment has been minimized.

Show comment
Hide comment
@brizou

brizou May 15, 2013

Here's what I have. after an hour this time (I had a lot of stuff opened in iceweasel, so itś normal if it takes a lot of ram)
http://brizou.fr/dropcenter/php/action.php?action=openFile&file=../uploads/Capture-5.png

my daemon.log
https://brizou.fr/zerobin/?d7a7f5a9c0dfa068#9i6F2EDEtyaB3l1c+qO9EGkv/cr4ws/GTBdHR4/OZYw=

gvfs seem to cause some problems but I can't remove it, a lot of softwares are using it

xsession-errors is empty

brizou commented May 15, 2013

Here's what I have. after an hour this time (I had a lot of stuff opened in iceweasel, so itś normal if it takes a lot of ram)
http://brizou.fr/dropcenter/php/action.php?action=openFile&file=../uploads/Capture-5.png

my daemon.log
https://brizou.fr/zerobin/?d7a7f5a9c0dfa068#9i6F2EDEtyaB3l1c+qO9EGkv/cr4ws/GTBdHR4/OZYw=

gvfs seem to cause some problems but I can't remove it, a lot of softwares are using it

xsession-errors is empty

@brizou

This comment has been minimized.

Show comment
Hide comment
@brizou

brizou May 16, 2013

Now I have tis line, a lot, in everything.log
May 16 15:47:14 clement-desktop slim[577]: (mate-settings-daemon:616): GLib-GObject-CRITICAL **: g_object_ref: assertion `G_IS_OBJECT (object)' failed

brizou commented May 16, 2013

Now I have tis line, a lot, in everything.log
May 16 15:47:14 clement-desktop slim[577]: (mate-settings-daemon:616): GLib-GObject-CRITICAL **: g_object_ref: assertion `G_IS_OBJECT (object)' failed

@sbalneav

This comment has been minimized.

Show comment
Hide comment
@sbalneav

sbalneav May 16, 2013

Are you running on fedora?

sbalneav commented May 16, 2013

Are you running on fedora?

@brizou

This comment has been minimized.

Show comment
Hide comment
@brizou

brizou May 16, 2013

no archlinux

brizou commented May 16, 2013

no archlinux

@MarkMT

This comment has been minimized.

Show comment
Hide comment
@MarkMT

MarkMT May 29, 2013

I'm seeing a similar problem... it seems that whenever I adjust monitor resolution settings memory increases significantly. Since I do this frequently as I change from laptop internal monitor to external monitor a couple of times a day, memory usage by mate-settings-daemon escalates rapidly. By the time I get to around 4GB the machine becomes unusable and I have to reboot.

MarkMT commented May 29, 2013

I'm seeing a similar problem... it seems that whenever I adjust monitor resolution settings memory increases significantly. Since I do this frequently as I change from laptop internal monitor to external monitor a couple of times a day, memory usage by mate-settings-daemon escalates rapidly. By the time I get to around 4GB the machine becomes unusable and I have to reboot.

@MarkMT

This comment has been minimized.

Show comment
Hide comment
@MarkMT

MarkMT May 29, 2013

BTW, mate-settings-daemon version 1.4.0-2+precise and Mint 14

MarkMT commented May 29, 2013

BTW, mate-settings-daemon version 1.4.0-2+precise and Mint 14

@tkyjovsk

This comment has been minimized.

Show comment
Hide comment
@tkyjovsk

tkyjovsk May 30, 2013

Hi, I have the same problem on Ubuntu 13.04 with mate-settings-daemon 1.6.0-2+raring. Whenever I open a popup menu of mate-display-properties tray icon, memory usage of the settings daemon jumps up to several GB.

tkyjovsk commented May 30, 2013

Hi, I have the same problem on Ubuntu 13.04 with mate-settings-daemon 1.6.0-2+raring. Whenever I open a popup menu of mate-display-properties tray icon, memory usage of the settings daemon jumps up to several GB.

@szesch

This comment has been minimized.

Show comment
Hide comment
@szesch

szesch May 30, 2013

Contributor

Is it just opening the menu that causes the increase in memory usage, or does it occur after you have preformed some action in the menu?

Contributor

szesch commented May 30, 2013

Is it just opening the menu that causes the increase in memory usage, or does it occur after you have preformed some action in the menu?

@MarkMT

This comment has been minimized.

Show comment
Hide comment
@MarkMT

MarkMT May 30, 2013

Just opening the display settings dialog is causing the problem in my case. About 100MB each time.

MarkMT commented May 30, 2013

Just opening the display settings dialog is causing the problem in my case. About 100MB each time.

@MarkMT

This comment has been minimized.

Show comment
Hide comment
@MarkMT

MarkMT May 30, 2013

BTW one other observation that may or may not be relevant... if I kill mate-settings-daemon, the desktop, app icons etc revert to a different low-res (or at least clunky) version. If I restart the process, the regular appearance of the desktop is mostly restored, but with one exception - Caja, which remains in the low-res state.

MarkMT commented May 30, 2013

BTW one other observation that may or may not be relevant... if I kill mate-settings-daemon, the desktop, app icons etc revert to a different low-res (or at least clunky) version. If I restart the process, the regular appearance of the desktop is mostly restored, but with one exception - Caja, which remains in the low-res state.

@Yasen6275

This comment has been minimized.

Show comment
Hide comment
@Yasen6275

Yasen6275 Aug 7, 2013

I have similar problem after hibernation. My system is Debian/testing. Usual programs running on my pc are icedove, iceweasel, chromium, skype(last non microsoft version). mate-settings-daemon cant be killed with sig 15 only with sig 9.

I'm note sure if the problem is in mate-settings-daemon or somewhere else because more rearly after hibernation i have problem with panel or a window opening and closing very fast with caption "caja x desctop" or something like that

Yasen6275 commented Aug 7, 2013

I have similar problem after hibernation. My system is Debian/testing. Usual programs running on my pc are icedove, iceweasel, chromium, skype(last non microsoft version). mate-settings-daemon cant be killed with sig 15 only with sig 9.

I'm note sure if the problem is in mate-settings-daemon or somewhere else because more rearly after hibernation i have problem with panel or a window opening and closing very fast with caption "caja x desctop" or something like that

@flexiondotorg

This comment has been minimized.

Show comment
Hide comment
@flexiondotorg

flexiondotorg Jan 2, 2014

Member

Similar report in the MATE forum for Arch.

Member

flexiondotorg commented Jan 2, 2014

Similar report in the MATE forum for Arch.

@DeveloperMCD

This comment has been minimized.

Show comment
Hide comment
@DeveloperMCD

DeveloperMCD Jan 4, 2014

I got this problem today on Linux Mint 16, and I'm using the latest version of MATE.

DeveloperMCD commented Jan 4, 2014

I got this problem today on Linux Mint 16, and I'm using the latest version of MATE.

@balwierz

This comment has been minimized.

Show comment
Hide comment
@balwierz

balwierz Jan 8, 2014

I confirm what MarkMT says: launching or even right clicking on display settings (as applet on mate-panel) causes a large jump of memory usage which is not freed when quitting the applet.

Arch Linux
mate-settings-daemon-pulseaudio 1.6.2
Will try with dev version 1.7

balwierz commented Jan 8, 2014

I confirm what MarkMT says: launching or even right clicking on display settings (as applet on mate-panel) causes a large jump of memory usage which is not freed when quitting the applet.

Arch Linux
mate-settings-daemon-pulseaudio 1.6.2
Will try with dev version 1.7

@balwierz

This comment has been minimized.

Show comment
Hide comment
@balwierz

balwierz Jan 8, 2014

Actually it is not launching of "Monitor Preferences" that causes the issue. It is right clicking on the notification area applet of it. In my case 4.7GB get allocated !!

balwierz commented Jan 8, 2014

Actually it is not launching of "Monitor Preferences" that causes the issue. It is right clicking on the notification area applet of it. In my case 4.7GB get allocated !!

@monsta

This comment has been minimized.

Show comment
Hide comment
@monsta

monsta Feb 17, 2014

Member

Another evidence of memory leak, this time in LMDE:
http://forums.linuxmint.com/viewtopic.php?f=198&t=159793

Member

monsta commented Feb 17, 2014

Another evidence of memory leak, this time in LMDE:
http://forums.linuxmint.com/viewtopic.php?f=198&t=159793

@stefano-k stefano-k added confirmed and removed unconfirmed labels Feb 17, 2014

@nahall

This comment has been minimized.

Show comment
Hide comment
@nahall

nahall Feb 18, 2014

I encountered this memory leak yesterday after upgrading my desktop to LDME UP8 (MATE 1.6.1-1). In my case, mate-settings-daemon was also using 100% CPU (one full core) in addition to gigabytes of RAM. Killing it made it respawn, but the respawned process started using 100% CPU and growing memory rapidly.

I noticed that the file .xsession-errors in my home directory was being filled with tons of lines of:

(mate-settings-daemon:4602): dconf-CRITICAL **: unable to create file '/run/user/1000/dconf/user': Permission denied.  dconf will not work properly.

every second (by the time I noticed, my .xsession-errors was over 500MB). I looked at the file /run/user/1000/dconf/user and it was set to have root permissions. I deleted the file, killed mate-settings-daemon, and now, when it respawned, it recreated that file as my user name, and now it doesn't seem to be using much CPU or memory. Not sure why the permissions got set wrong. I'm guessing it has something to do with sudo.

nahall commented Feb 18, 2014

I encountered this memory leak yesterday after upgrading my desktop to LDME UP8 (MATE 1.6.1-1). In my case, mate-settings-daemon was also using 100% CPU (one full core) in addition to gigabytes of RAM. Killing it made it respawn, but the respawned process started using 100% CPU and growing memory rapidly.

I noticed that the file .xsession-errors in my home directory was being filled with tons of lines of:

(mate-settings-daemon:4602): dconf-CRITICAL **: unable to create file '/run/user/1000/dconf/user': Permission denied.  dconf will not work properly.

every second (by the time I noticed, my .xsession-errors was over 500MB). I looked at the file /run/user/1000/dconf/user and it was set to have root permissions. I deleted the file, killed mate-settings-daemon, and now, when it respawned, it recreated that file as my user name, and now it doesn't seem to be using much CPU or memory. Not sure why the permissions got set wrong. I'm guessing it has something to do with sudo.

@leo-unglaub

This comment has been minimized.

Show comment
Hide comment
@leo-unglaub

leo-unglaub Mar 3, 2014

I have the same problem on Debian sience a few days. mate-settings-daemon is using up to 800 MB of ram.

mate-settings-daemon-memory-usage

Greetings
Leo

leo-unglaub commented Mar 3, 2014

I have the same problem on Debian sience a few days. mate-settings-daemon is using up to 800 MB of ram.

mate-settings-daemon-memory-usage

Greetings
Leo

@stefano-k

This comment has been minimized.

Show comment
Hide comment
@stefano-k

stefano-k Mar 3, 2014

Member

@LeoUnglaub something more to debug the problem? are you changing wallpaper often? do you have something interesting in .xsession-errors? are you using systemd? thanks

Member

stefano-k commented Mar 3, 2014

@LeoUnglaub something more to debug the problem? are you changing wallpaper often? do you have something interesting in .xsession-errors? are you using systemd? thanks

@leo-unglaub

This comment has been minimized.

Show comment
Hide comment
@leo-unglaub

leo-unglaub Mar 3, 2014

Hey,
i am still at trying to reproduce it. Sadly the memory map is not very helpful, because all large memory users are [anon]. The only large element there is icon-theme.cache.

http://paste.debian.net/plain/85032

Greetings
Leo

leo-unglaub commented Mar 3, 2014

Hey,
i am still at trying to reproduce it. Sadly the memory map is not very helpful, because all large memory users are [anon]. The only large element there is icon-theme.cache.

http://paste.debian.net/plain/85032

Greetings
Leo

@3dbloke

This comment has been minimized.

Show comment
Hide comment
@3dbloke

3dbloke Mar 7, 2014

The same problem occurs with my LMDE 201403 (FINAL) Mate installation.

I've noticed it when using the Sound Preferences and VLC 2.1.1, with a Logitech 9000 USB webcam attached (trying to record video), while running System Monitor 1.6.1.

The same memory leak also happened using the Gnome-Sound-Recorder 3.4.0, again with Sound Preferences open and System Monitor.

In both cases, mate-system-daemon took around 90-100 percent of the CPU on my 32-bit dual core Intel T2500 2GHz system, with 3.2GB addressable memory.

As others have said,if the daemon is killed it restarts with the same bad behaviour.

I've been unable to reproduce the problem. I'll post here again if I can reliably do so.

--Thomas

3dbloke commented Mar 7, 2014

The same problem occurs with my LMDE 201403 (FINAL) Mate installation.

I've noticed it when using the Sound Preferences and VLC 2.1.1, with a Logitech 9000 USB webcam attached (trying to record video), while running System Monitor 1.6.1.

The same memory leak also happened using the Gnome-Sound-Recorder 3.4.0, again with Sound Preferences open and System Monitor.

In both cases, mate-system-daemon took around 90-100 percent of the CPU on my 32-bit dual core Intel T2500 2GHz system, with 3.2GB addressable memory.

As others have said,if the daemon is killed it restarts with the same bad behaviour.

I've been unable to reproduce the problem. I'll post here again if I can reliably do so.

--Thomas

@catalin-hritcu

This comment has been minimized.

Show comment
Hide comment
@catalin-hritcu

catalin-hritcu Mar 8, 2014

Same problem here, also with LMDE 201403. I think the fact that '/run/user/1000/dconf/user' has the wrong (root) permissions is crucial for this bug, and probably mate-settings-daemon is not the main culprit here, but whichever sudo-ed process broke those permissions. Looking at my 340MB .xsession-errors is seems that a lot of other processes (nm-applet, emacs, mate-power-manager, etc) have trouble once the permissions are corrupted. Some of them react more graciously than others, and mate-settings-daemon reacts particularly ungracefuly by eating up 1 CPU, 6GB of RAM and 340MB of .xsessions. As far as I can tell, the main workaround at the moment is deleting the offending file and killing mate-settings-daemon. On my machine it took around half an hour until it started eating memory again ... but not yet 1 CPU.

catalin-hritcu commented Mar 8, 2014

Same problem here, also with LMDE 201403. I think the fact that '/run/user/1000/dconf/user' has the wrong (root) permissions is crucial for this bug, and probably mate-settings-daemon is not the main culprit here, but whichever sudo-ed process broke those permissions. Looking at my 340MB .xsession-errors is seems that a lot of other processes (nm-applet, emacs, mate-power-manager, etc) have trouble once the permissions are corrupted. Some of them react more graciously than others, and mate-settings-daemon reacts particularly ungracefuly by eating up 1 CPU, 6GB of RAM and 340MB of .xsessions. As far as I can tell, the main workaround at the moment is deleting the offending file and killing mate-settings-daemon. On my machine it took around half an hour until it started eating memory again ... but not yet 1 CPU.

@catalin-hritcu

This comment has been minimized.

Show comment
Hide comment
@catalin-hritcu

catalin-hritcu Mar 8, 2014

I think I've found the culprit for the wrong permissions: The Mint Software manager.

hritcu@detained ~ $ ls -l /run/user/1000/dconf/user
ls: cannot access /run/user/1000/dconf/user: No such file or directory
[2]hritcu@detained ~ $ gksu mintinstall
glibtop: Non-standard uts for running kernel:
release 3.11-2-amd64=3.11.0 gives version code 199424

No bp log location saved, using default.
[000:000] Cpu: 6.60.3, x8, 2401Mhz, 15763MB
[000:000] Computer model: Not available
[000:000] Browser XEmbed support present: 1
[000:000] Browser toolkit is Gtk2.
[000:000] Using Gtk2 toolkit
No bp log location saved, using default.
[000:000] Cpu: 6.60.3, x8, 2401Mhz, 15763MB
[000:000] Computer model: Not available
[000:002] Warning(optionsfile.cc:47): Load: Could not open file, err=2
[000:002] No bp log location saved, using default.
[000:002] Cpu: 6.60.3, x8, 2401Mhz, 15763MB
[000:002] Computer model: Not available
[000:002] Browser XEmbed support present: 1
[000:002] Browser toolkit is Gtk2.
[000:003] Using Gtk2 toolkit
[000:002] Warning(optionsfile.cc:47): Load: Could not open file, err=2
[000:002] No bp log location saved, using default.
[000:002] Cpu: 6.60.3, x8, 2401Mhz, 15763MB
[000:002] Computer model: Not available
add_categories took 0.522 ms
build_matched_packages took 0.121 ms
java version "1.7.0_21"
OpenJDK Runtime Environment (IcedTea 2.3.9) (7u21-2.3.9-5)
OpenJDK 64-Bit Server VM (build 23.7-b01, mixed mode)
add_packages took 2175.822 ms
add_reviews took 308.270 ms
__init__ took 2913.610 ms
show_category took 3.648 ms
Killed
hritcu@detained ~ $ ls -l /run/user/1000/dconf/user
-rw------- 1 root root 2 Mar  8 17:39 /run/user/1000/dconf/user

catalin-hritcu commented Mar 8, 2014

I think I've found the culprit for the wrong permissions: The Mint Software manager.

hritcu@detained ~ $ ls -l /run/user/1000/dconf/user
ls: cannot access /run/user/1000/dconf/user: No such file or directory
[2]hritcu@detained ~ $ gksu mintinstall
glibtop: Non-standard uts for running kernel:
release 3.11-2-amd64=3.11.0 gives version code 199424

No bp log location saved, using default.
[000:000] Cpu: 6.60.3, x8, 2401Mhz, 15763MB
[000:000] Computer model: Not available
[000:000] Browser XEmbed support present: 1
[000:000] Browser toolkit is Gtk2.
[000:000] Using Gtk2 toolkit
No bp log location saved, using default.
[000:000] Cpu: 6.60.3, x8, 2401Mhz, 15763MB
[000:000] Computer model: Not available
[000:002] Warning(optionsfile.cc:47): Load: Could not open file, err=2
[000:002] No bp log location saved, using default.
[000:002] Cpu: 6.60.3, x8, 2401Mhz, 15763MB
[000:002] Computer model: Not available
[000:002] Browser XEmbed support present: 1
[000:002] Browser toolkit is Gtk2.
[000:003] Using Gtk2 toolkit
[000:002] Warning(optionsfile.cc:47): Load: Could not open file, err=2
[000:002] No bp log location saved, using default.
[000:002] Cpu: 6.60.3, x8, 2401Mhz, 15763MB
[000:002] Computer model: Not available
add_categories took 0.522 ms
build_matched_packages took 0.121 ms
java version "1.7.0_21"
OpenJDK Runtime Environment (IcedTea 2.3.9) (7u21-2.3.9-5)
OpenJDK 64-Bit Server VM (build 23.7-b01, mixed mode)
add_packages took 2175.822 ms
add_reviews took 308.270 ms
__init__ took 2913.610 ms
show_category took 3.648 ms
Killed
hritcu@detained ~ $ ls -l /run/user/1000/dconf/user
-rw------- 1 root root 2 Mar  8 17:39 /run/user/1000/dconf/user
@catalin-hritcu

This comment has been minimized.

Show comment
Hide comment
@catalin-hritcu

catalin-hritcu Mar 8, 2014

Returning to mate-settings-daemon, it seems that about any error (not just the permission problem with /run/user/1000/dconf/user) causes it to leak memory and fill .xsession-errors with zillions of repeated error messages. Here is another one:

    (mate-settings-daemon:4635): GLib-GObject-CRITICAL **: g_object_unref: assertion 'G_IS_OBJECT (object)' failed

I'm getting 1.7MB of these messages in the .xsession-errors and the mate-settings-daemon takes 2.6GB RAM at the moment. No 100% CPU though.

mate-settings-demon

catalin-hritcu commented Mar 8, 2014

Returning to mate-settings-daemon, it seems that about any error (not just the permission problem with /run/user/1000/dconf/user) causes it to leak memory and fill .xsession-errors with zillions of repeated error messages. Here is another one:

    (mate-settings-daemon:4635): GLib-GObject-CRITICAL **: g_object_unref: assertion 'G_IS_OBJECT (object)' failed

I'm getting 1.7MB of these messages in the .xsession-errors and the mate-settings-daemon takes 2.6GB RAM at the moment. No 100% CPU though.

mate-settings-demon

@3dbloke

This comment has been minimized.

Show comment
Hide comment
@3dbloke

3dbloke Mar 9, 2014

Following up my earlier comment, the problem occurred again today after I had been listening to some OGG podcasts using VLC (v2.1.1). As before, CPU is running high with mate-settings-daemon on 80-90 percent, and memory use increasing by around 2MB every few seconds. It was the unexpected whirring of my laptop's cooling fan that drew my attention to the problem. I had not touched any of the Mate settings recently. Other apps running: Firefox, Scrivener, Terminal, Deluge, CryptKeeper, Shutter. (no webcam attached this time)

inxi -F
System: Host: whatever Kernel: 3.11-2-686-pae i686 (32 bit) Desktop: MATE 1.6.1 Distro: LinuxMint 1 debian
Machine: System: Dell product: MM061
Mobo: Dell model: 0XD720 Bios: Dell version: A17 date: 06/13/2007
CPU: Dual core Intel CPU T2500 (-MCP-) cache: 2048 KB flags: (nx pae sse sse2 sse3 vmx)
Clock Speeds: 1: 2000.00 MHz 2: 2000.00 MHz
Graphics: Card: Advanced Micro Devices [AMD/ATI] RV515/M54 [Mobility Radeon X1400]
X.Org: 1.14.3 drivers: ati,radeon (unloaded: fbdev,vesa) Resolution: 1680x1050@60.1hz
GLX Renderer: Gallium 0.4 on ATI RV515 GLX Version: 2.1 Mesa 9.2.2
Audio: Card: Intel NM10/ICH7 Family High Definition Audio Controller driver: snd_hda_intel
Sound: Advanced Linux Sound Architecture ver: k3.11-2-686-pae
Network: Card-1: Broadcom BCM4401-B0 100Base-TX driver: b44
IF: eth0 state: down mac: 00:15:c5:aa:ca:0f
Card-2: Intel PRO/Wireless 3945ABG [Golan] Network Connection driver: iwl3945
IF: wlan0 state: up mac: 00:13:02:c9:b6:d0
Drives: HDD Total Size: 500.1GB (27.4% used) 1: id: /dev/sda model: ST9500420AS size: 500.1GB
Partition: ID: / size: 29G used: 4.6G (17%) fs: ext4 ID: /home size: 426G used: 124G (31%) fs: ext4
ID: swap-1 size: 4.19GB used: 0.00GB (0%) fs: swap
Sensors: System Temperatures: cpu: 54.5C mobo: N/A
Fan Speeds (in rpm): cpu: N/A
Info: Processes: 161 Uptime: 2 days Memory: 1617.4/3293.3MB Client: Shell (bash) inxi: 1.9.14

3dbloke commented Mar 9, 2014

Following up my earlier comment, the problem occurred again today after I had been listening to some OGG podcasts using VLC (v2.1.1). As before, CPU is running high with mate-settings-daemon on 80-90 percent, and memory use increasing by around 2MB every few seconds. It was the unexpected whirring of my laptop's cooling fan that drew my attention to the problem. I had not touched any of the Mate settings recently. Other apps running: Firefox, Scrivener, Terminal, Deluge, CryptKeeper, Shutter. (no webcam attached this time)

inxi -F
System: Host: whatever Kernel: 3.11-2-686-pae i686 (32 bit) Desktop: MATE 1.6.1 Distro: LinuxMint 1 debian
Machine: System: Dell product: MM061
Mobo: Dell model: 0XD720 Bios: Dell version: A17 date: 06/13/2007
CPU: Dual core Intel CPU T2500 (-MCP-) cache: 2048 KB flags: (nx pae sse sse2 sse3 vmx)
Clock Speeds: 1: 2000.00 MHz 2: 2000.00 MHz
Graphics: Card: Advanced Micro Devices [AMD/ATI] RV515/M54 [Mobility Radeon X1400]
X.Org: 1.14.3 drivers: ati,radeon (unloaded: fbdev,vesa) Resolution: 1680x1050@60.1hz
GLX Renderer: Gallium 0.4 on ATI RV515 GLX Version: 2.1 Mesa 9.2.2
Audio: Card: Intel NM10/ICH7 Family High Definition Audio Controller driver: snd_hda_intel
Sound: Advanced Linux Sound Architecture ver: k3.11-2-686-pae
Network: Card-1: Broadcom BCM4401-B0 100Base-TX driver: b44
IF: eth0 state: down mac: 00:15:c5:aa:ca:0f
Card-2: Intel PRO/Wireless 3945ABG [Golan] Network Connection driver: iwl3945
IF: wlan0 state: up mac: 00:13:02:c9:b6:d0
Drives: HDD Total Size: 500.1GB (27.4% used) 1: id: /dev/sda model: ST9500420AS size: 500.1GB
Partition: ID: / size: 29G used: 4.6G (17%) fs: ext4 ID: /home size: 426G used: 124G (31%) fs: ext4
ID: swap-1 size: 4.19GB used: 0.00GB (0%) fs: swap
Sensors: System Temperatures: cpu: 54.5C mobo: N/A
Fan Speeds (in rpm): cpu: N/A
Info: Processes: 161 Uptime: 2 days Memory: 1617.4/3293.3MB Client: Shell (bash) inxi: 1.9.14

@monsta

This comment has been minimized.

Show comment
Hide comment
@monsta
Member

monsta commented Jul 9, 2014

@linas

This comment has been minimized.

Show comment
Hide comment
@linas

linas Nov 1, 2014

Still happening with the latest Mint17 qiana release.(based on ubuntu 14.04)

I'm leaking 1-2 gigbytes/minute! so it blows out system ram in about 5 minutes or less. Everything was fine until I started a google hangout session.

~/.xsession-errors is filled with zillions of these:
(mate-panel:2767): dconf-CRITICAL **: unable to create file '/run/user/1000/dconf/user': Permission denied. dconf will not work properly.

cat .xsession-errors |grep "dconf-CRIT" |wc
15282244 229233660 2269203289

OK, so 15 million of these errors ... bad ...

linas commented Nov 1, 2014

Still happening with the latest Mint17 qiana release.(based on ubuntu 14.04)

I'm leaking 1-2 gigbytes/minute! so it blows out system ram in about 5 minutes or less. Everything was fine until I started a google hangout session.

~/.xsession-errors is filled with zillions of these:
(mate-panel:2767): dconf-CRITICAL **: unable to create file '/run/user/1000/dconf/user': Permission denied. dconf will not work properly.

cat .xsession-errors |grep "dconf-CRIT" |wc
15282244 229233660 2269203289

OK, so 15 million of these errors ... bad ...

@linas

This comment has been minimized.

Show comment
Hide comment
@linas

linas Nov 1, 2014

OK, so I quickly found the suggested work-around: remove systemd and libpam-systemd as per
http://forums.linuxmint.com/viewtopic.php?f=198&t=159793&start=20#p835353

However, it unclear if this work-around will render a mint-17 system unbootable ...

At any rate, mate-settings-daemon should not leak memory just because of some bad file permissions...

linas commented Nov 1, 2014

OK, so I quickly found the suggested work-around: remove systemd and libpam-systemd as per
http://forums.linuxmint.com/viewtopic.php?f=198&t=159793&start=20#p835353

However, it unclear if this work-around will render a mint-17 system unbootable ...

At any rate, mate-settings-daemon should not leak memory just because of some bad file permissions...

@monsta

This comment has been minimized.

Show comment
Hide comment
@monsta

monsta Nov 1, 2014

Member

However, it unclear if this work-around will render a mint-17 system unbootable

It shouldn't as Mint/Ubuntu uses upstart as its init system (and systemd-sysv isn't installed).

Member

monsta commented Nov 1, 2014

However, it unclear if this work-around will render a mint-17 system unbootable

It shouldn't as Mint/Ubuntu uses upstart as its init system (and systemd-sysv isn't installed).

@linas

This comment has been minimized.

Show comment
Hide comment
@linas

linas Nov 1, 2014

Hmm .. in my case, systemd was not actually installed. Removing libpam-systemd will cause a few dozen packages to get removed, including mate-panel and mate-applets, so that seems like a non-starter.

linas commented Nov 1, 2014

Hmm .. in my case, systemd was not actually installed. Removing libpam-systemd will cause a few dozen packages to get removed, including mate-panel and mate-applets, so that seems like a non-starter.

@monsta

This comment has been minimized.

Show comment
Hide comment
@monsta

monsta Nov 2, 2014

Member

Ok, so no easy way out. Anyway, you can try to catch the moment /run/user/1000/dconf/user gets its ownership changed to root:root (that's the cause of mate-settings-daemon losing its mind).

For example, in Debian Testing I can always reproduce the ownership change by running pluma via gksu (see this bug report).
Try to catch it. Run various apps via gksu, check that file's ownership by running ls -l /run/user/1000/dconf/user, then (if needed) change it back by running sudo chown you:you /run/user/1000/dconf/user, and so on.

Member

monsta commented Nov 2, 2014

Ok, so no easy way out. Anyway, you can try to catch the moment /run/user/1000/dconf/user gets its ownership changed to root:root (that's the cause of mate-settings-daemon losing its mind).

For example, in Debian Testing I can always reproduce the ownership change by running pluma via gksu (see this bug report).
Try to catch it. Run various apps via gksu, check that file's ownership by running ls -l /run/user/1000/dconf/user, then (if needed) change it back by running sudo chown you:you /run/user/1000/dconf/user, and so on.

@linas

This comment has been minimized.

Show comment
Hide comment
@linas

linas Nov 3, 2014

OK, so I can reproduce this simply by running pluma as root. Gory details of strace/ltrace are in the debian bug report https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=766464 and that it is happening very very early in gtk initialization.

A quick google reveals this: https://bugzilla.redhat.com/show_bug.cgi?id=753882 which reveals that:

  1. the bug is more than 3 years old
  2. it has bitten hundreds if not thousands of users
  3. the culprit is pam_systemd which is "working as designed"
  4. pam_systemd is looking at the environment variable XDG_RUNTIME_DIR which is set to /run/usr/1000 for most folks. The resulting file is clobbered. Try it: export XDG_RUNTIME_DIR=/run/user/bogus and then run any MATE/gtk/gnome program as root, and you will discover the file /run/user/bogus/dconf/user has been created and is owned by root.

So:

  1. mate-settings-daemon still has to be fixed to not leak 16GBytes of RAM in 3-4 minutes
  2. Someone needs to track down the XDG_RUNTIME_DIR thing, and fix it.

linas commented Nov 3, 2014

OK, so I can reproduce this simply by running pluma as root. Gory details of strace/ltrace are in the debian bug report https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=766464 and that it is happening very very early in gtk initialization.

A quick google reveals this: https://bugzilla.redhat.com/show_bug.cgi?id=753882 which reveals that:

  1. the bug is more than 3 years old
  2. it has bitten hundreds if not thousands of users
  3. the culprit is pam_systemd which is "working as designed"
  4. pam_systemd is looking at the environment variable XDG_RUNTIME_DIR which is set to /run/usr/1000 for most folks. The resulting file is clobbered. Try it: export XDG_RUNTIME_DIR=/run/user/bogus and then run any MATE/gtk/gnome program as root, and you will discover the file /run/user/bogus/dconf/user has been created and is owned by root.

So:

  1. mate-settings-daemon still has to be fixed to not leak 16GBytes of RAM in 3-4 minutes
  2. Someone needs to track down the XDG_RUNTIME_DIR thing, and fix it.
@linas

This comment has been minimized.

Show comment
Hide comment
@linas

linas Nov 3, 2014

Doh. Wrote too soon. Regarding point 2) Lennart Poettering himself weighs in and states: its not a bug, its a feature: See: https://bugzilla.redhat.com/show_bug.cgi?id=753882#c29 and commeent 31, with a cogent rebuttal in comment 34. A plausible fix in comment 35 Poettering is in denial in comment 42 while comment 43 shows the killer nature of the bug. Then there's comment 56 ... my eyes glaze over after a while. I finally understand why Poettering gets death threats, and why systemd is so widely and strongly hated. I'm not even using systemd, and I got stabbed in the back by it. Makes me angry.

Anyway: mate-settings-daemon still has to be fixed to not leak 16GBytes of RAM in 3-4 minutes

linas commented Nov 3, 2014

Doh. Wrote too soon. Regarding point 2) Lennart Poettering himself weighs in and states: its not a bug, its a feature: See: https://bugzilla.redhat.com/show_bug.cgi?id=753882#c29 and commeent 31, with a cogent rebuttal in comment 34. A plausible fix in comment 35 Poettering is in denial in comment 42 while comment 43 shows the killer nature of the bug. Then there's comment 56 ... my eyes glaze over after a while. I finally understand why Poettering gets death threats, and why systemd is so widely and strongly hated. I'm not even using systemd, and I got stabbed in the back by it. Makes me angry.

Anyway: mate-settings-daemon still has to be fixed to not leak 16GBytes of RAM in 3-4 minutes

@monsta

This comment has been minimized.

Show comment
Hide comment
@monsta

monsta May 30, 2015

Member

@clefebvre: looks like your latest systemd patch is needed in Mint 17.x too...

Member

monsta commented May 30, 2015

@clefebvre: looks like your latest systemd patch is needed in Mint 17.x too...

@linas

This comment has been minimized.

Show comment
Hide comment
@linas

linas Jul 17, 2015

Happened again, just now.

linas commented Jul 17, 2015

Happened again, just now.

@CoolAller

This comment has been minimized.

Show comment
Hide comment
@CoolAller

CoolAller Nov 13, 2015

It is impossible to use DE MATE. All the same error described above (using 100% CPU and memory leak.)
strace -f $(pidof mate-settings-daemon | sed 's/([0-9]*)/-p \1/g'):

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

This continues from 2013, is it really impossible to fix? Do something with this error, please!
DE MATE 1.8.1 Debian 8 Jessie with the most recent updates.

CoolAller commented Nov 13, 2015

It is impossible to use DE MATE. All the same error described above (using 100% CPU and memory leak.)
strace -f $(pidof mate-settings-daemon | sed 's/([0-9]*)/-p \1/g'):

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

This continues from 2013, is it really impossible to fix? Do something with this error, please!
DE MATE 1.8.1 Debian 8 Jessie with the most recent updates.

@raveit65

This comment has been minimized.

Show comment
Hide comment
@raveit65

raveit65 Nov 13, 2015

Member

permission probs with /run/user/1000/dconf/user is an very old systemd/pam prob,
see https://bugzilla.redhat.com/show_bug.cgi?id=753882
I suggest to bother the real culprit.

Member

raveit65 commented Nov 13, 2015

permission probs with /run/user/1000/dconf/user is an very old systemd/pam prob,
see https://bugzilla.redhat.com/show_bug.cgi?id=753882
I suggest to bother the real culprit.

@CoolAller

This comment has been minimized.

Show comment
Hide comment
@CoolAller

CoolAller Nov 13, 2015

This error was before Systemd - using 100% CPU and memory leak, even when using sysvinit. So I wouldn't say that to blame systemd.

CoolAller commented Nov 13, 2015

This error was before Systemd - using 100% CPU and memory leak, even when using sysvinit. So I wouldn't say that to blame systemd.

@raveit65

This comment has been minimized.

Show comment
Hide comment
@raveit65

raveit65 Nov 13, 2015

Member

i only mentioned permission probs with /run/user/1000/dconf/user,
which is well known prob with systemd

Member

raveit65 commented Nov 13, 2015

i only mentioned permission probs with /run/user/1000/dconf/user,
which is well known prob with systemd

@CoolAller

This comment has been minimized.

Show comment
Hide comment
@CoolAller

CoolAller Nov 13, 2015

Thanks for the reply!
There is at least some information about what it is someone is going to fix in systemd?

CoolAller commented Nov 13, 2015

Thanks for the reply!
There is at least some information about what it is someone is going to fix in systemd?

@usmarine2141

This comment has been minimized.

Show comment
Hide comment
@usmarine2141

usmarine2141 Jul 30, 2016

There is memory leak still going on. using 30gb of RAM and only have 1 terminal, sys monitor, FF open up. any idea when this will be fixed?

usmarine2141 commented Jul 30, 2016

There is memory leak still going on. using 30gb of RAM and only have 1 terminal, sys monitor, FF open up. any idea when this will be fixed?

@CoolAller

This comment has been minimized.

Show comment
Hide comment
@CoolAller

CoolAller Sep 9, 2016

@usmarine2141, I created a bug report on the Debian's bug tracking system.There I was told that the problem is not related to systemd. Debian's support said that the alleged need to make corrections in sudo. In any case, the error is not corrected to this day and I think it will not be fixed ever, since this issue has a lot of years and no one wants to solve it. Unfortunately I do not have sufficient competence to solve the problem yourself.

Developers of Linux Mint have decided to fix the bug themselves and posted a patch here:
linuxmint/systemd-betsy@f7ab85f

If you are like me using Debian 8 Jessie, I can share the collected packets with applying the patch:
systemd_215-17+deb8u3_amd64: https://yadi.sk/d/EPyCNwF5rczCP
systemd_215-17+deb8u3_i386: https://yadi.sk/d/1iNA4JrxrczCF
md5sums systemd_215-17+deb8u3_amd64: https://yadi.sk/d/gLb5tf3qrd3DR
md5sums systemd_215-17+deb8u3_i386: https://yadi.sk/d/Ks4oJr5Drd3DP

I hope it will help someone.

CoolAller commented Sep 9, 2016

@usmarine2141, I created a bug report on the Debian's bug tracking system.There I was told that the problem is not related to systemd. Debian's support said that the alleged need to make corrections in sudo. In any case, the error is not corrected to this day and I think it will not be fixed ever, since this issue has a lot of years and no one wants to solve it. Unfortunately I do not have sufficient competence to solve the problem yourself.

Developers of Linux Mint have decided to fix the bug themselves and posted a patch here:
linuxmint/systemd-betsy@f7ab85f

If you are like me using Debian 8 Jessie, I can share the collected packets with applying the patch:
systemd_215-17+deb8u3_amd64: https://yadi.sk/d/EPyCNwF5rczCP
systemd_215-17+deb8u3_i386: https://yadi.sk/d/1iNA4JrxrczCF
md5sums systemd_215-17+deb8u3_amd64: https://yadi.sk/d/gLb5tf3qrd3DR
md5sums systemd_215-17+deb8u3_i386: https://yadi.sk/d/Ks4oJr5Drd3DP

I hope it will help someone.

@linas

This comment has been minimized.

Show comment
Hide comment
@linas

linas Sep 9, 2016

@CoolAller can you share the Debian ticket number with us? I thought I described the problem quite closely, in #44 (comment) and #44 (comment) and I'm thinking that the Debian maintainer(s) did not see these and/or did not understand the nature of the bug.

linas commented Sep 9, 2016

@CoolAller can you share the Debian ticket number with us? I thought I described the problem quite closely, in #44 (comment) and #44 (comment) and I'm thinking that the Debian maintainer(s) did not see these and/or did not understand the nature of the bug.

linas referenced this issue in linuxmint/systemd-betsy Sep 9, 2016

@linas

This comment has been minimized.

Show comment
Hide comment
@linas

linas Sep 9, 2016

FWIW, besides the patch linuxmint/systemd-betsy@f7ab85f mentioned above, it is also claimed that https://cgit.freedesktop.org/systemd/systemd/commit/?id=baae0358f349870544884e405e82e4be7d8add9f fixes the bug, but this is not entirely clear. The debian bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=766464 was closed, based on that claim, so if the bug is still recurring, then the bug report was incorrectly closed.

linas commented Sep 9, 2016

FWIW, besides the patch linuxmint/systemd-betsy@f7ab85f mentioned above, it is also claimed that https://cgit.freedesktop.org/systemd/systemd/commit/?id=baae0358f349870544884e405e82e4be7d8add9f fixes the bug, but this is not entirely clear. The debian bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=766464 was closed, based on that claim, so if the bug is still recurring, then the bug report was incorrectly closed.

@CoolAller

This comment has been minimized.

Show comment
Hide comment
@CoolAller

CoolAller Sep 9, 2016

@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.

CoolAller commented Sep 9, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@linas

linas Sep 9, 2016

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 commented Sep 9, 2016

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

This comment has been minimized.

Show comment
Hide comment
@linas

linas Sep 9, 2016

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.

linas commented Sep 9, 2016

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

This comment has been minimized.

Show comment
Hide comment
@CoolAller

CoolAller Sep 9, 2016

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

CoolAller commented Sep 9, 2016

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

@CoolAller

This comment has been minimized.

Show comment
Hide comment
@CoolAller

CoolAller Sep 9, 2016

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))

CoolAller commented Sep 9, 2016

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

This comment has been minimized.

Show comment
Hide comment
@monsta

monsta Sep 12, 2016

Member

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.

Member

monsta commented Sep 12, 2016

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

This comment has been minimized.

Show comment
Hide comment
@monsta

monsta Sep 12, 2016

Member

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)... 😆

Member

monsta commented Sep 12, 2016

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)... 😆

@sbalneav

This comment has been minimized.

Show comment
Hide comment
@sbalneav

sbalneav Sep 14, 2016

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?

sbalneav commented Sep 14, 2016

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

This comment has been minimized.

Show comment
Hide comment
@usmarine2141

usmarine2141 Sep 14, 2016

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
#44 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ATwSo7ou8y1mRQrQ9c-QbNCp-zm8zr7Pks5qqFzQgaJpZM4Am_JY
.

usmarine2141 commented Sep 14, 2016

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
#44 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ATwSo7ou8y1mRQrQ9c-QbNCp-zm8zr7Pks5qqFzQgaJpZM4Am_JY
.

@roschacker

This comment has been minimized.

Show comment
Hide comment
@roschacker

roschacker Mar 26, 2017

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

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

screenshot at 2017-03-26 21-28-54-mate-settings-daemon
screenshot at 2017-03-26 21-21-18-mate-settings-daemon
get_apt_cache py-screenshot at 2017-03-26 21-00-51

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 #44 (comment)

roschacker commented Mar 26, 2017

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

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

screenshot at 2017-03-26 21-28-54-mate-settings-daemon
screenshot at 2017-03-26 21-21-18-mate-settings-daemon
get_apt_cache py-screenshot at 2017-03-26 21-00-51

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 #44 (comment)

@CoolAller

This comment has been minimized.

Show comment
Hide comment
@CoolAller

CoolAller Mar 27, 2017

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: linuxmint/systemd-betsy@f7ab85f
PS. I'm already sick of recompiling Systemd packages. Maintainers do not pay any attention to user complaints.

CoolAller commented Mar 27, 2017

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: linuxmint/systemd-betsy@f7ab85f
PS. I'm already sick of recompiling Systemd packages. Maintainers do not pay any attention to user complaints.

@mootensai

This comment has been minimized.

Show comment
Hide comment
@mootensai

mootensai May 26, 2017

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

mootensai commented May 26, 2017

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 comment has been minimized.

Show comment
Hide comment
@jggouvea

jggouvea Jul 2, 2017

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.

jggouvea commented Jul 2, 2017

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.

@h3rzkasper

This comment has been minimized.

Show comment
Hide comment
@h3rzkasper

h3rzkasper Jul 26, 2017

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.

h3rzkasper commented Jul 26, 2017

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

This comment has been minimized.

Show comment
Hide comment
@dmknght

dmknght Sep 24, 2017

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.

dmknght commented Sep 24, 2017

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 comment has been minimized.

Show comment
Hide comment
@gentoo90

gentoo90 Dec 21, 2017

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.

gentoo90 commented Dec 21, 2017

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

This comment has been minimized.

Show comment
Hide comment
@monsta

monsta Dec 24, 2017

Member

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

Member

monsta commented Dec 24, 2017

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

@gentoo90

This comment has been minimized.

Show comment
Hide comment
@gentoo90

gentoo90 Dec 25, 2017

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

gentoo90 commented Dec 25, 2017

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

@monsta

This comment has been minimized.

Show comment
Hide comment
@monsta

monsta Dec 29, 2017

Member

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)?

Member

monsta commented Dec 29, 2017

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

This comment has been minimized.

Show comment
Hide comment
@gentoo90

gentoo90 Dec 29, 2017

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?

gentoo90 commented Dec 29, 2017

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

This comment has been minimized.

Show comment
Hide comment
@monsta

monsta Jan 17, 2018

Member

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.

Member

monsta commented Jan 17, 2018

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

This comment has been minimized.

Show comment
Hide comment
@lukefromdc

lukefromdc Jan 17, 2018

Member

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

Member

lukefromdc commented Jan 17, 2018

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

@linas

This comment has been minimized.

Show comment
Hide comment
@linas

linas Jan 17, 2018

@lukefromdc Please see the #44 (comment) and the comments that follow, and also #44 (comment)

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 .

linas commented Jan 17, 2018

@lukefromdc Please see the #44 (comment) and the comments that follow, and also #44 (comment)

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

This comment has been minimized.

Show comment
Hide comment
@lukefromdc

lukefromdc Jan 17, 2018

Member

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.

Member

lukefromdc commented Jan 17, 2018

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

This comment has been minimized.

Show comment
Hide comment
@monsta

monsta Jan 18, 2018

Member

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.

Member

monsta commented Jan 18, 2018

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

This comment has been minimized.

Show comment
Hide comment
@nudgegoonies

nudgegoonies Mar 4, 2018

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 commented Mar 4, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment