Bug 921689 - reports CRITICAL errors and complains dconf will not work properly.
Summary: reports CRITICAL errors and complains dconf will not work properly.
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: emacs   
(Show other bugs)
Version: 25
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Petr Hracek
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords: Reopened
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-03-14 16:57 UTC by Jos de Kloe
Modified: 2017-12-12 10:26 UTC (History)
19 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-12-12 10:26:44 UTC
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)

Description Jos de Kloe 2013-03-14 16:57:05 UTC
Description of problem:

after using 'su - someuser' to work as another user, emacs produces this kind of warnings when launched:

$ emacs Makefile 

** (emacs:30641): WARNING **: Couldn't register with accessibility bus: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.

** (emacs:30641): CRITICAL **: unable to create directory '/run/user/1000/dconf': Permission denied.  dconf will not work properly.

** (emacs:30641): CRITICAL **: unable to create directory '/run/user/1000/dconf': Permission denied.  dconf will not work properly.

** (emacs:30641): CRITICAL **: unable to create directory '/run/user/1000/dconf': Permission denied.  dconf will not work properly.

** (emacs:30641): CRITICAL **: unable to create directory '/run/user/1000/dconf': Permission denied.  dconf will not work properly.

** (emacs:30641): CRITICAL **: unable to create directory '/run/user/1000/dconf': Permission denied.  dconf will not work properly.

The user that runs emacs has UID 1005 on my system, so it surely is correct that emacs cannot create things below /run/user/1000/

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

emacs-24.2-6.fc18.x86_64
fvwm-2.6.5-3.fc18.x86_64

How reproducible:

always

Steps to Reproduce:
1. use fvwm as window manager (not sure if it is important, but just to be complete)
2. open an xterm
3. issue the command "su - someuser"
4. issue the command "emacs somefile"
  
Actual results:

screaming errors/warnings in the terminal used to launch emacs, even if the editor itself seems to work just fine.

Expected results:

no warnings/errors should be printed when starting emacs as it seems to work properly.

Additional info:

Comment 1 David Howells 2013-05-24 11:53:26 UTC
I'm seeing this too:

warthog>stg edit
Invoking the editor: "emacs .stgit-edit.txt" ... 
** (process:16937): CRITICAL **: unable to create file '/run/user/4043/dconf/user': Permission denied.  dconf will not work properly.

** (process:16937): CRITICAL **: unable to create file '/run/user/4043/dconf/user': Permission denied.  dconf will not work properly.

** (process:16937): CRITICAL **: unable to create file '/run/user/4043/dconf/user': Permission denied.  dconf will not work properly.

** (process:16937): CRITICAL **: unable to create file '/run/user/4043/dconf/user': Permission denied.  dconf will not work properly.

** (process:16937): CRITICAL **: unable to create file '/run/user/4043/dconf/user': Permission denied.  dconf will not work properly.

Looking in the directory:

warthog>ls -l /run/user/4043/dconf
total 4
-rw-------. 1 root root 2 May 22 17:44 user

Which would likely be due to me doing su and then emacsing something as root.  Hexdumping the file just shows a couple of zero bytes contained therein.

I'm using KDE rather than fvwm.

Comment 2 David Howells 2013-05-24 11:56:41 UTC
chowning the file to myself seems to fix the problem.  Deleting the file also seems to work - it's recreated with a pair of zero bytes in it.

Comment 3 Devrim Gündüz 2013-07-11 13:18:58 UTC
I can confirm that this also happens with Evolution on my F-19 box. Chown fixed the issue as written in comment #2.

Comment 4 Steven Ellis 2013-07-27 21:38:46 UTC
I've got the same issues on F-19.

I xhost + local: to allow access to my X session then su - to a different user

running most gnome applications produces

(gthumb:10588): dconf-CRITICAL **: unable to create directory '/run/user/500/dconf': Permission denied.  dconf will not work properly.


user 500 owns the X session

Comment 5 The PowerTool 2013-08-12 13:56:12 UTC
I'm experiencing this exact same issue on a freshly installed system:

[root@p7-1456c ~]# uname -a
Linux p7-1456c.localdomain 3.9.11-200.fc18.x86_64 #1 SMP Mon Jul 22 21:04:50 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

One other possibly important item:

[root@p7-1456c ~]# getenforce
Disabled

Detailed messages, for reference:
http://pastebin.com/sZHzNrG4 (part 1 of 2)
http://pastebin.com/ZcZLpJYQ (part 2 of 2)

I was working in gnome and suddenly nothing responded other than the mouse.  I could move the mouse but the screen was locked.  I sshed into the system and killed the gnome session which dropped me back to the GUI logon.  Attempting to logon I received an "oops" message and got bumped back to the GUI logon.

Next reading the above information I removed /run/user/1000/dconf/user and then was allowed to logon successfully.

I lost everything that was open.

Comment 6 Richard Allen 2013-08-22 18:01:53 UTC
This is hitting me so frequently that I am seriously considering going back to f18.

Comment 7 The PowerTool 2013-08-23 05:11:58 UTC
It's an issue in both 18 and 19.  Look at my details, above (f18).

Comment 8 Sergio Monteiro Basto 2013-12-20 02:34:37 UTC
export XDG_RUNTIME_DIR=/run/user/1000

fixes the warning for me ... , don't know if fixes something really

Comment 9 thomas.lynch 2014-02-01 05:36:19 UTC
[root@localhost ~]# uname -a
Linux localhost.localdomain 3.12.8-300.fc20.x86_64 #1 SMP Thu Jan 16 01:07:50 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

I'm having the same problem in F20. The system freezes, wakes up, freezes again. After rebooting the logs show: 


This message repeated 20 times: [about how many times the system froze]
Jan 30 19:32:00 localhost.localdomain gnome-session[1608]: dconf-CRITICAL: unable to create file '/run/user/1000/dconf/user': Permission denied.  dconf will not work properly.
[Then]
-- Reboot --

As I am just instaling the system, after I log in on my user account it is common that I have an su -l  in a gnome-terminal and then spawn some emacs sessions from that.

Comment 10 Jos de Kloe 2014-04-17 09:32:00 UTC
for me the original problem with emacs disappeared for F20.

Issuing a command like this:
   export XDG_RUNTIME_DIR=/run/user/$UID
actually brings back the problem again.

In my case there does not exist a directory /run/user/$PID/ for the alternative username that I use as mentioned above.

Comment 11 Jean-Baptiste Lab 2014-08-30 05:09:06 UTC
I just experienced this on fresh LMDE 201403 install and fixed it like so:

sudo chown -R <user>.<user> /run/user/1000/dconf/

The dconf directory was owned by root.root, probably after some sudo commands.

Hope this helps

Comment 12 roger griffiths 2015-01-01 14:41:33 UTC
This is not an emacs issue. For me it started with Fedora 21 (I did not appear to have the problem before the upgrade). This same message appears with other applications launched at the prompt, such as gedit (but not leafpad); and others if you look in the .xsession-errors file.
As others elsewhere have observed, adding:

export NO_AT_BRIDGE=1

to the .bashrc file causes the errors not to show, and eliminates that delay in starting the application. 

This does not seem like a fix, but more like addressing a symptom.

Comment 13 Fedora End Of Life 2015-01-09 17:46:17 UTC
This message is a notice that Fedora 19 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 19. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

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 19 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 14 Fedora End Of Life 2015-02-17 14:51:42 UTC
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 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.

Comment 15 Ari Lemmke 2015-12-26 04:48:18 UTC
This bug is still there with Fedora 23 (Mate desktop)

Terminal:

# su
# nautilus --browser &

(nautilus:14494): dconf-CRITICAL **: unable to create file '/run/user/1000/dconf/user': Permission denied.  dconf will not work properly.

And the whole desktop functionality (wm) gets locked for a loooong while.

This bug is not emacs releated.

This is possibly a design problem and should be WONTFIX and meaning
that users which need to use su (sysadmins etc.) should consider to drop
gnome desktops.

//arl

----

(Hope you one day get/construct a bug tracking system which
automatically links old EOL bugs to new releases when they
are still open and not fixed. So one does not end up posting
to old CLOSED bugs .. which still are open with new release.

Search gives only open bug Bug 896648 when used search keywords:
Permission denied.  dconf will not work properly.

Still: please do not close bugs when EOL just move to as new release
bugs. I do undestand statistics look much better when there are
no open bugs but new version does not automatically fix old bugs)

Comment 16 Sergio Monteiro Basto 2015-12-26 04:52:18 UTC
feel free to reopen it

Comment 17 Ari Lemmke 2015-12-26 13:54:41 UTC
Sorry, but I do not have any permissions.
(you should have guessed that).

Would have done F19 -> F23 and changed status -> OPEN, priority -> medium

or status -> WONTFIX

---

General question:

I don't now if it is better to whine in G+ or write Bugzilla
bugs. Have installed Fedora 23 to HP Elitebooks 8760w and 8770w,
my current work engines, and have had tremendeous problems with
Wi-Fi (installation lacks proper firmware), Sound (Intel HD audio
is visible but is not visible), and DVD burning (blanks will be automounted,
but not visible to brasero etc.), DVD automounting (getting rid of it), etc.

Seems like lots of old problems/bugs (2010/2012/even older) are popping up again.

Bugzilla itself should, i.e. the end result should be before closing
a test script. Do know HW dependent bugs cannot be tested but the most
common ones should create unit type test script as an end result and
without it bugs should not be able to be closed.

//arl

Comment 18 Sergio Monteiro Basto 2015-12-26 23:10:42 UTC
(In reply to Ari Lemmke from comment #17)
if you are have an fas account or something like this, you should be able to reopen this bug, is not need great permissions. I won't open it because don't know if it is a bug really . 

IIRC this is almost an inoffensive warning and as comment #8 states : 

export XDG_RUNTIME_DIR=/run/user/1000

fixes the warning for me ... 

https://ask.fedoraproject.org/ is a good place to start to ask

Comment 19 Ari Lemmke 2015-12-30 13:03:51 UTC
This situation makes desktop switching impossible for 5 or so minutes.

Have autohide for panels and only current desktop may be used because
panels won't be available (using 16 desktops).

The real problem is not the printed messages. The problem is DOS situation.

I think this will escalate to situation where you will end up having
mate-panel sending you:

Could not launch application
Failed to fork (Cannot allocate memory)

Even though have 0.5GB free memory and 4GB free swap.
(starting programs directly using shell works, like gnome-terminal &)

This escalation is really old bug too. From 2012 or earlier.

mate-panel --replace

fixes it but it is just a kludge and not a real fix.

Do you think a normal user / person / people are able to use
export XDG_RUNTIME_DIR=/run/user/1000
etc. commands / managing shell environment?
(I do know that Fedora is not even intended for common people.)

Comment 20 Francisco de la Peña 2016-01-09 17:56:07 UTC
See #1296778. Smells like a SELinux permission issue in F23.

Comment 21 RobbieTheK 2017-03-02 18:50:35 UTC
Seeing this on Fedora 25:

Mar 01 01:01:02 myworkstation run-parts[5606]: (/etc/cron.hourly) starting 0anacron
Mar 01 01:01:02 myworkstation anacron[5615]: Anacron started on 2017-03-01
Mar 01 01:01:02 myworkstation run-parts[5617]: (/etc/cron.hourly) finished 0anacron
Mar 01 01:01:03 myworkstation anacron[5615]: Normal exit (0 jobs run)
Mar 01 01:10:17 myworkstation tracker-extract[1960]: unable to create file '/run/user/1202/dconf/user': Permission denied.  dconf will not work properly.
Mar 01 01:11:08 myworkstation tracker-store[2034]: Could not create FTS delete statement: table fts5 has no column named nco:hobby
Mar 01 01:13:33 myworkstation tracker-extract[1960]: Could not insert metadata for item "file:///home/users/ts/Desktop/file.pptx": Unable to insert multiple values for subject `urn:uuid:ca3fad20-5dc8-49c1-8d26-50a8e36bd5
Mar 01 01:13:33 myworkstation tracker-extract[1960]: If the error above is recurrent for the same item/ID, consider running "tracker-extract" in the terminal with the TRACKER_VERBOSITY=3 environment variable, and filing a bug with the additional information

Comment 22 RobbieTheK 2017-04-19 14:52:35 UTC
As per my previous comments this seems related to Tracker and especially when Tracker runs during a backup, e.g., a tar of large files like /home, and tries to index places like the Trash. I uninstalled Tracker and the messages go away.

Comment 23 David Novák 2017-06-26 06:21:53 UTC
This could be relevant to this bug: https://bugzilla.gnome.org/show_bug.cgi?id=779342

Comment 24 Fedora End Of Life 2017-11-16 19:16:57 UTC
This message is a reminder that Fedora 25 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 25. 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 '25'.

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 25 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 25 Fedora End Of Life 2017-12-12 10:26:44 UTC
Fedora 25 changed to end-of-life (EOL) status on 2017-12-12. Fedora 25 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.