Bug 1282874 - GNOME Shell crashes after su
GNOME Shell crashes after su
Product: Fedora
Classification: Fedora
Component: systemd (Show other bugs)
Unspecified Unspecified
unspecified Severity high
: ---
: ---
Assigned To: systemd-maint
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2015-11-17 12:05 EST by Cedric Sodhi
Modified: 2015-11-18 04:25 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2015-11-18 03:48:38 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Cedric Sodhi 2015-11-17 12:05:52 EST
I encountered a bug described here [1] by Gawain Lynch. I will quote the content of that page:

>I hit a rather interesting 'feature' in systemd recently where doing an ` su - 
` and then running a GUI application before switching back and executing one as your normal user will cause GNOME shell to lock-up.
> Examining /var/log/messages I found a series of messages similar to:
> gnome-session[NNNN]: CRITICAL: unable to create file '/run/user/1000/dconf/user': 
> Permission denied. dconf will not work properly.
> [...]
> What in effect happens, is that the file /run/user/1000/dconf/user becomes owned by the root user
> [...]
> Fortunately the workaround is quite easy. Simply add this to the root users .bash_profile :
> export XDG_RUNTIME_DIR=/run/user/0

[1] http://gawainlynch.com/gnome-shell-crashes-after-su
Comment 1 Jan Synacek 2015-11-18 03:48:38 EST
Sorry, but random rants from the Internet are not the way to file bug reports.

Anyway, I can't reproduce this.

1) su -
2) gedit
3) exit
4) gedit

Nothing locks up, things work as expected.
Comment 2 Cedric Sodhi 2015-11-18 04:25:54 EST
When I said "I encountered" I meant that I actually experienced that bug myself, several times. It's only that the cited page (which I found searching for "/run/user/1000/dconf/user Permission denied" and "systemd" on Google) seems to give a reasonable explanation, though I can not yet confirm with absolute certainty that the workarround does the trick.

To my knowledge, to reproduce this will have to follow a login/boot, so that no other GTK (dconf?) application ran before? I will try in more detail when I have time, in the meantime someone else may want to try.

Note You need to log in before you can comment on or make changes to this bug.