Bug 956306 - gnome shell freezes when window is present from su session
gnome shell freezes when window is present from su session
Status: CLOSED EOL
Product: Fedora
Classification: Fedora
Component: dconf (Show other bugs)
20
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Matthias Clasen
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-04-24 11:56 EDT by Garrett Mitchener
Modified: 2015-06-29 07:54 EDT (History)
26 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-06-29 07:54:58 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
dconfsu.patch (898 bytes, patch)
2013-08-21 06:27 EDT, manuel.BACHMANN@eurogiciel.fr
no flags Details | Diff

  None (edit)
Description Garrett Mitchener 2013-04-24 11:56:34 EDT
Description of problem:


Version-Release number of selected component (if applicable):

gnome-shell-3.6.3.1-1.fc18.x86_64

How reproducible: regularly


Steps to Reproduce:

- log in to gnome
- open a terminal
- run 'su -' in that terminal, become root
- run 'gedit' in that terminal, wait for it to appear
- move the mouse to the upper left hot corner
  
Actual results:
- gnome shell freezes

Expected results:
- app screen


Additional info:
I can ssh into the frozen machine, and 'kill -9 -1' successfully kills X and gnome and returns the machine to GDM.  I'm using two monitors.
Comment 1 Garrett Mitchener 2013-04-24 12:19:38 EDT
No freeze if I use xterm instead of gedit.  So it must be a gnome thing.

Also if I kill gnome-shell via ssh and I can get a terminal to accept the keyboard, I can run gnome-shell --replace and get back to a working gnome session.
Comment 2 p.johns 2013-04-29 04:05:29 EDT
I also see this using su, sudo and beesu to open graphical programs as root on f18.
using pkexec instead works though.
Comment 3 Gareth Jones 2013-05-11 16:07:36 EDT
I see this too.

~/.cache/gdm/session.log fills up with several megabytes of

Window manager warning: Log level 8: unable to create file '/run/user/1000/dconf/user': Permission denied.  dconf will not work properly.
Window manager warning: Log level 8: unable to create file '/run/user/1000/dconf/user': Permission denied.  dconf will not work properly.
Window manager warning: Log level 8: unable to create file '/run/user/1000/dconf/user': Permission denied.  dconf will not work properly.
[...]
Comment 4 Satish Balay 2013-06-05 11:27:31 EDT
gnome-shell-3.8.2-3.fc19.x86_64
dconf-0.16.0-1.fc19.x86_64


I've been having these freezes with virt-manager running local virtual machines [which involves root/sudo access]. And I didn't know what the issue was - until I noticed the dconf-CRITICAL messages in /var/log/messages.

I'm puzzled if anyone is able to use VMs on F19 without encountering this issue.
And I don't remember seeing this issue with F18.

My previous work-arround was to login via console to a console [Alt-Ctl-F2] - and do 'killall -HUP gnome-session' - but occasionally this would crash gnome in such a way that I couldn't login again without reboot.

Now I see deleting /run/user/1000/dconf/user restores gnome-shell to working state. Will see if this one keeps working

----------
Jun  5 10:07:54 asterix /etc/gdm/Xsession[1625]: (gnome-settings-daemon:1827): dconf-CRITICAL **: unable to create file '/run/user/1000/dconf/user': Permission denied.  dconf will not work properly.
Jun  5 10:07:54 asterix /etc/gdm/Xsession[1625]: (gnome-settings-daemon:1827): dconf-CRITICAL **: unable to create file '/run/user/1000/dconf/user': Permission denied.  dconf will not work properly.
Jun  5 10:07:54 asterix /etc/gdm/Xsession[1625]: (gnome-settings-daemon:1827): dconf-CRITICAL **: unable to create file '/run/user/1000/dconf/user': Permission denied.  dconf will not work properly.
Jun  5 10:07:55 asterix /etc/gdm/Xsession[1625]: (gnome-settings-daemon:1827): dconf-CRITICAL **: unable to create file '/run/user/1000/dconf/user': Permission denied.  dconf will not work properly.


[root@asterix log]# grep 'dconf-CRITICAL' /var/log/messages* |wc -l
2122005
[root@asterix log]# grep 'dconf-CRITICAL' /var/log/messages* |grep /etc/gdm/Xsession | wc -l
2117838
[root@asterix log]# grep 'dconf-CRITICAL' /var/log/messages* |grep gnome-session | wc -l
8335
[root@asterix log]#
Comment 5 Satish Balay 2013-06-14 10:16:39 EDT
Is this a f19 blocker bug?

is anyone able use VMs with virt-manager on f19?
Comment 6 manuel.BACHMANN@eurogiciel.fr 2013-08-21 06:27:26 EDT
Created attachment 788786 [details]
dconfsu.patch

This bug is caused by :

https://bugzilla.redhat.com/show_bug.cgi?id=753882

In short : gedit and gnome-shell use dconf, which iself uses XDG_RUNTIME_DIR to determine in which folder it should store the shared memory file.

Problem is, as we switched to systemd, the new PAM-systemd behaviour is to NOT reload the XDG_RUNTIME_DIR variable whenever we use su.
For instance, the folder is "/run/user/1000", I do "su <user>", the new user folder is still "/run/user/1000".

So the new user tries to overwrite the old user's file.

It's normally impossible, as the file has 0700 permissions ; however root can do that.

See attached patch for dconf, who forces root to use another folder. It's not supposed to be a well-fitted fix ; I'd like to have some feedback, though.
Comment 7 Michael Schwendt 2013-11-02 12:17:24 EDT
I've run into this with Fedora 20 today:
https://lists.fedoraproject.org/pipermail/test/2013-November/118623.html
Comment 8 antonio montagnani 2013-11-02 12:25:30 EDT
same as  Michael but on Fedora 19. It is quite erratic, not always happens
Comment 9 Florian Müllner 2013-11-02 18:51:33 EDT
(In reply to manuel.BACHMANN@eurogiciel.fr from comment #6)
> Created attachment 788786 [details]
> dconfsu.patch

You leak dconfdir.
Comment 10 Florian Müllner 2013-11-02 18:55:49 EDT
This is not a problem we can or should workaround in gnome-shell. No idea really whether this should be addressed in dconf, su or systemd - the attached patch is for dconf, so let's put it there.
Comment 11 Flóki Pálsson 2013-11-05 18:15:11 EST
This is in Beta RC3 Fedora-20-Beta-x86_64-DVD.iso and no yum update.
I have senn this in live beta rc2.  But it not after  yum update.
Comment 12 Colin Guthrie 2013-11-11 13:32:28 EST
Adding myself to CC as we have the same prob in Mageia. Personally I don't like the fix and would rather discourage users from running anything GUI based via su and directly them towards sudo instead which actually tries to clean out the environment a little bit (unlike su which is uber simple). dconf is just one rather visible manifestation of the problems that occur running anything reasonably high level via a su shell - it's certainly not unique and thus I feel it's the wrong place to putting such a fix. That said, it may be the most pragmatic approach in the short term. I'd be interested to get Matthias' opinion certainly :)
Comment 13 Garrett Mitchener 2013-11-11 13:48:57 EST
I'm seeing this as a user interface issue as much as anything: The desktop environment should not freeze up under any reasonable circumstances.
Comment 14 Colin Guthrie 2013-11-17 13:25:03 EST
(In reply to Florian Müllner from comment #9)
> (In reply to manuel.BACHMANN@eurogiciel.fr from comment #6)
> > Created attachment 788786 [details]
> > dconfsu.patch
> 
> You leak dconfdir.

The patch also doesn't work. "if (getuid != 0)" is always true... you want "if (getuid() != 0)"
Comment 15 Sam Roza 2014-03-12 12:11:19 EDT
This still appears to be broken. I have been in a battle of wills with F20 when using virt-manager. The workstation will freeze up for up to 6 minutes at a time. I cannot change context, though the mouse pointer moves freely. Eventually, I get an ABRT popup explaining that there was a gnome-shell problem, and things go back to normal.

There are the familiar DCONF messages in /var/log/messages:

Mar 12 08:49:50 unknown3CA9F4189F80 gnome-session[1737]: dconf-CRITICAL: unable to create file '/run/user/1000/dconf/user': Permission denied.  dconf will not work properly.
Mar 12 08:49:51 unknown3CA9F4189F80 gnome-session[1737]: dconf-CRITICAL: unable to create file '/run/user/1000/dconf/user': Permission denied.  dconf will not work properly.
Mar 12 08:49:52 unknown3CA9F4189F80 gnome-session[1737]: dconf-CRITICAL: unable to create file '/run/user/1000/dconf/user': Permission denied.  dconf will not work properly.

It also appears to peg my CPUs, and causes some other side-effects.

Would this not happen if the logged-in gnome user started the virt-manager process; as opposed to root?
Comment 16 RamtinA 2014-04-04 10:08:47 EDT
I have this problem to and this happends everytime , so i can't do my jobs most of time .
Comment 17 Sam Roza 2014-06-24 17:38:39 EDT
An update:

I found that if virt-manager is run as root while logged in as another user, this occurs. If I run virt-manager as the local non-root user, I have no issues. I have been running for months without issues since discovering that.
Comment 18 Michael Petlan 2015-01-02 14:46:50 EST
I have met the issue running Evolution on RHEL 7 with KDE. Really interesting.
Comment 19 Fedora End Of Life 2015-05-29 05:01:11 EDT
This message is a reminder that Fedora 20 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 20. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '20'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 20 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 20 Fedora End Of Life 2015-06-29 07:54:58 EDT
Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

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