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.
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.
I also see this using su, sudo and beesu to open graphical programs as root on f18. using pkexec instead works though.
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. [...]
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]#
Is this a f19 blocker bug? is anyone able use VMs with virt-manager on f19?
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.
I've run into this with Fedora 20 today: https://lists.fedoraproject.org/pipermail/test/2013-November/118623.html
same as Michael but on Fedora 19. It is quite erratic, not always happens
(In reply to manuel.BACHMANN from comment #6) > Created attachment 788786 [details] > dconfsu.patch You leak dconfdir.
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.
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.
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 :)
I'm seeing this as a user interface issue as much as anything: The desktop environment should not freeze up under any reasonable circumstances.
(In reply to Florian Müllner from comment #9) > (In reply to manuel.BACHMANN 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)"
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?
I have this problem to and this happends everytime , so i can't do my jobs most of time .
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.
I have met the issue running Evolution on RHEL 7 with KDE. Really interesting.
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.
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.