memory usage #44

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

Projects

None yet
@brizou
brizou commented Apr 25, 2013 edited

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
sbalneav commented May 9, 2013

Has this problem re-ocurred for you?

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

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

Are you running on fedora?

@brizou
brizou commented May 16, 2013

no archlinux

@MarkMT
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
MarkMT commented May 29, 2013

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

@tkyjovsk

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
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
MarkMT commented May 30, 2013

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

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

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
Member

Similar report in the MATE forum for Arch.

@DeveloperMCD

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

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

@LeoUnglaub

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

@LeoUnglaub

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

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

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

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
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
Member
monsta commented Jul 9, 2014
@linas
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
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
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
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
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
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
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 monsta referenced this issue in mate-desktop/mate-system-monitor Dec 16, 2014
Closed

Memory leak in disk usage tab #40

@gustopn
gustopn commented May 15, 2015

Yes monitor notifications is where I tracked down the problem also. I have opened a separate issue back then, it seems to be caused by the same problem.

@linas
linas commented May 29, 2015

After 6 months of no problems at all, it suddenly came back fast and furious, just now. No clue what triggered it, this time. FWIW I am using the latest and greatest Mint Rebecca. To recap:

The symptoms are:

  1. ~/.xsession-errors is huge -- 1.6GB
  2. it is filled with this error message:
    dconf-CRITICAL **: unable to create file '/run/user/1000/dconf/user': Permission denied. dconf will not work properly.
  3. /run/user/1000/dconf/usr was owned by root with perms 600

The work-around is:

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.

@monsta
Member
monsta commented May 30, 2015

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

@linas
linas commented Jul 17, 2015

Happened again, just now.

@CoolAller

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

@CoolAller

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
Member

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

@CoolAller

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

@usmarine2141

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

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

@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 linas referenced this issue in linuxmint/systemd-betsy Sep 9, 2016
@clefebvre clefebvre pam_systemd: Set XDG_RUNTIME_DIR=/run/user/0 when the UID is 0 and di…
…fferent than the original one
f7ab85f
@linas
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
CoolAller commented Sep 9, 2016 edited

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

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

@CoolAller
CoolAller commented Sep 9, 2016 edited

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

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

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