Bug 452930 – dev-util/meld-1.7.0 - glib.GError: Configuration server couldn't be contacted: D-BUS error: Can't overwrite existing read-only value: Value for `/apps/gnome-settings/meld/history-fileentry' set in a read-only source at the front of your configuration path

• Status: RESOLVED TEST-REQUEST
• Product: Gentoo Linux

[Description Juergen Rose 2013-01-19 09:50:46 UTC]

I am logged in as user rose via gdm on "impala" then I open an xterm and switched to root. root opens a ssh session to "rose@lynx2". Then I switched there to root (su - root) and tried to start meld. This opens for a second a meld window which then crashed with:

* (meld:28138): WARNING **: Couldn't connect to accessibility bus: Failed to connect to socket /tmp/dbus-8vGozcS5Ux: Connection refused
Traceback (most recent call last):
  File "/usr/bin/meld", line 154, in <module>
    main()
  File "/usr/bin/meld", line 146, in main
    new_window = app.parse_args(sys.argv[1:])
  File "/usr/lib64/meld/meld/meldapp.py", line 206, in parse_args
    tab = open_paths(args, options.auto_compare, options.auto_merge)
  File "/usr/lib64/meld/meld/meldwindow.py", line 696, in open_paths
    tab = self.append_diff(paths, auto_compare, auto_merge)
  File "/usr/lib64/meld/meld/meldwindow.py", line 664, in append_diff
    return self.append_filediff(paths)
  File "/usr/lib64/meld/meld/meldwindow.py", line 627, in append_filediff
    doc.set_files(files)
  File "/usr/lib64/meld/meld/filediff.py", line 957, in set_files
    self.fileentry[i].prepend_history(absfile)
  File "/usr/lib64/meld/meld/ui/historyentry.py", line 355, in prepend_history
    self.__gentry.prepend_text(text)
  File "/usr/lib64/meld/meld/ui/historyentry.py", line 135, in prepend_text
    self.__insert_history_item(text, True)
  File "/usr/lib64/meld/meld/ui/historyentry.py", line 130, in __insert_history_item
    self._save_history()
  File "/usr/lib64/meld/meld/ui/historyentry.py", line 116, in _save_history
    self.__gconf_client.set_list(key, gconf.VALUE_STRING, gconf_items)
glib.GError: Configuration server couldn't be contacted: D-BUS error: Can't overwrite existing read-only value: Value for `/apps/gnome-settings/meld/history-fileentry' set in a read-only source at the front of your configuration path


The /tmp/dbus-8vGozcS5Ux does not exist:

Then I start an additional ssh session on "lynx2", switched again to root, start again meld, and get the same error. Also restarting of dbus (/etc/init.d/dbus restart) on "lynx2" does not change anything.


Then I start a ssh session to an other system "lynx", switched to root and start meld. Now I get the same warning about connection to the same socket but meld does not crash:

** (meld:24169): WARNING **: Couldn't connect to accessibility bus: Failed to connect to socket /tmp/dbus-8vGozcS5Ux: Connection refused


Thus, it seems, it is the local dbus at "impala", which complains. BTW., I can't find any /tmp/dbus* file on any system. If I switch back to user rose at "lynx2" (exit) and start 'meld', I get the same warning about accessibility bus, but meld works. Switching again to root lets meld crash.

[Comment 1 Juergen Rose 2013-01-19 10:11:12 UTC]

I now suppose, that the warning about "Couldn't connect to accessibility bus" and error "Can't overwrite existing read-only value: Value for `/apps/gnome-settings/meld/history-fileentry'" are two different problems. 
I can list the gconf key /apps/gnome-settings/meld/history-fileentry at "lynx2":

root@lynx2:/root(48)# gconftool-2 -R /apps/gnome-settings/meld
 history-fileentry = [/etc/conf.d/net.Home_WLAN0,/etc/hosts.Home,/etc/portage/make.conf,/etc/logrotate.d/._cfg0000_syslog-ng,/home_caiman/rose/Txt/Configurations/sys_config.caiman/qlist_-ICv,/root/sys_config/emerge_-pvueDN_system_|_sort,/root/sys_config/emerge_--info,/home_caiman/rose/Txt/Configurations/etc/xdg/menus/applications.menu,/home_caiman/rose/Txt/Configurations/etc/portage/package.use]

But why is this key read-only?

[Comment 2 Juergen Rose 2013-01-19 10:24:33 UTC]

I suppose the key /apps/gnome-settings/meld/history-fileentry is saved in 
~/.gconf/apps/gnome-settings/meld/%gconf.xml. This file looks rather normal:

root@lynx2:/root(63)# ll .gconf/apps/gnome-settings/meld/%gconf.xml 
-rw------- 1 root root 1036 Jan 12 22:38 .gconf/apps/gnome-settings/meld/%gconf.xml
root@lynx2:/root(64)# cat  .gconf/apps/gnome-settings/meld/%gconf.xml 
<?xml version="1.0"?>
<gconf>
        <entry name="history-fileentry" mtime="1358026647" type="list" ltype="string">
                <li type="string">
                        <stringvalue>/etc/conf.d/net.Home_WLAN0</stringvalue>
                </li>
                <li type="string">
                        <stringvalue>/etc/hosts.Home</stringvalue>
                </li>
                <li type="string">
                        <stringvalue>/etc/portage/make.conf</stringvalue>
                </li>
                <li type="string">
                        <stringvalue>/etc/logrotate.d/._cfg0000_syslog-ng</stringvalue>
                </li>
                <li type="string">
                        <stringvalue>/home_caiman/rose/Txt/Configurations/sys_config.caiman/qlist_-ICv</stringvalue>
                </li>
                <li type="string">
                        <stringvalue>/root/sys_config/emerge_-pvueDN_system_|_sort</stringvalue>
                </li>
                <li type="string">
                        <stringvalue>/root/sys_config/emerge_--info</stringvalue>
                </li>
                <li type="string">
                        <stringvalue>/home_caiman/rose/Txt/Configurations/etc/xdg/menus/applications.menu</stringvalue>
                </li>
                <li type="string">
                        <stringvalue>/home_caiman/rose/Txt/Configurations/etc/portage/package.use</stringvalue>
                </li>
        </entry>
</gconf>

[Comment 3 Juergen Rose 2013-01-19 13:59:38 UTC]

A similar problem at the next system. "condor" is just rebooted. Nobody is logged in at the console. I opened a root ssh session from "impala" to "condor" and try to compare with meld to files at "condor":

  root@condor:/root(3)# meld /etc/apache2/modules.d/99_nagios3.conf /home_caiman/rose/Txt/Configurations/etc/apache2/modules.d/99_nagios3.conf

** (meld:8287): WARNING **: Couldn't connect to accessibility bus: Failed to connect to socket /tmp/dbus-8vGozcS5Ux: Connection refused

(meld:8287): GConf-WARNING **: Client failed to connect to the D-BUS daemon:
Failed to connect to socket /tmp/dbus-kr3n2u0aNi: Connection refused
Traceback (most recent call last):
  File "/usr/bin/meld", line 154, in <module>
    main()
  File "/usr/bin/meld", line 136, in main
    import meld.meldapp
  File "/usr/lib64/meld/meld/meldapp.py", line 216, in <module>
    app = MeldApp()
  File "/usr/lib64/meld/meld/meldapp.py", line 113, in __init__
    self.prefs = preferences.MeldPreferences()
  File "/usr/lib64/meld/meld/preferences.py", line 259, in __init__
    super(MeldPreferences, self).__init__("/apps/meld", self.defaults)
  File "/usr/lib64/meld/meld/util/prefs.py", line 93, in __init__
    self._gconf.add_dir(rootkey, gconf.CLIENT_PRELOAD_NONE)
glib.GError: No D-BUS daemon running

root@condor:/root(4)# /etc/init.d/dbus status
 * status: started
root@condor:/root(5)# qlist -Iv meld
dev-util/meld-1.7.0

[Comment 4 Juergen Rose 2013-01-19 14:06:26 UTC]

Some minutes later I try again to open two files with meld, emacs and gedit:

root@condor:/root(10)# meld /etc/apache2/modules.d/99_nagios3.conf /home_caiman/rose/Txt/Configurations/etc/apache2/modules.d/99_nagios3.conf_orca 

** (meld:8452): WARNING **: Couldn't connect to accessibility bus: Failed to connect to socket /tmp/dbus-8vGozcS5Ux: Connection refused
The program 'meld' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadAccess (attempt to access private resource denied)'.
  (Details: serial 229 error_code 10 request_code 130 minor_code 1)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)

'meld' fails.


root@condor:/root(11)# emacs /etc/apache2/modules.d/99_nagios3.conf /home_caiman/rose/Txt/Configurations/etc/apache2/modules.d/99_nagios3.conf_orca 

** (emacs:8464): WARNING **: Couldn't connect to accessibility bus: Failed to connect to socket /tmp/dbus-8vGozcS5Ux: Connection refused

'emacs' works like a charm.


root@condor:/root(12)# gedit /etc/apache2/modules.d/99_nagios3.conf /home_caiman/rose/Txt/Configurations/etc/apache2/modules.d/99_nagios3.conf_orca 

** (gedit:8469): WARNING **: Couldn't connect to accessibility bus: Failed to connect to socket /tmp/dbus-8vGozcS5Ux: Connection refused

** (gedit:8469): CRITICAL **: atk_bridge_adaptor_cleanup: assertion `inited' failed

'gedit' does not have any problems.

[Comment 5 Juergen Rose 2013-01-21 10:21:20 UTC]

To comment 1-2: If I am running meld locally at "lynx2" or if I log in via ssh from an other computer than "impala" e.g. from "caiman" I can run meld without problems. Could it be, that the local dbus at "impala" and not the dbus at "lynx2" complains about the read-only value of /apps/gnome-settings/meld/history-fileentry?

[Comment 6 Juergen Rose 2013-01-22 09:42:17 UTC]

If I understand Comment 7 of bug 440240 correctly, it was suggested, to use 'su -' instead of 'su' to get a clean environment for meld and to check the running dbus processes and DBUS_SESSION_BUS_ADDRESS. I found that DBUS_SESSION_BUS_ADDRESS is empty at all systems, the number of running dbus proccesses vary.

If I run meld locally at "impala", I have the following situation:

root@impala:/root(10)# echo $DBUS_SESSION_BUS_ADDRESS

root@impala:/root(11)# ps waux | grep dbus |grep -v grep
root     13076  0.0  0.0  24404   588 pts/0    S    07:28   0:00 dbus-launch --autolaunch 5a68222d62ffa27375642b1a00157350 --binary-syntax --close-stderr
root     13077  0.0  0.0  19688  1444 ?        Ss   07:28   0:00 /usr/bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session
message+ 25679  0.0  0.0  20640  1884 ?        Ss   Jan13   0:02 /usr/bin/dbus-daemon --system
rose     29536  0.0  0.0  24392   188 ?        S    Jan13   0:00 /usr/bin/dbus-launch --exit-with-session /usr/bin/ssh-agent -- gnome-session
rose     29537  0.0  0.0  21340  2384 ?        Ss   Jan13   0:10 /usr/bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session
rose     29544  0.0  0.0  19796  1508 ?        S    Jan13   0:00 /usr/bin/dbus-daemon --config-file=/etc/at-spi2/accessibility.conf --nofork --print-address 3
root@impala:/root(12)# LC_ALL=C meld .bash_profile ~rose/.bash_profile

I have two dbus processes for root and everything is fine, if I use a ssh connection from "impala" to "caiman", it looks like:

root@caiman:/root(37)# echo $DBUS_SESSION_BUS_ADDRESS

root@caiman:/root(38)# ps waux | grep dbus |grep -v grep
message+  4792  0.0  0.0  20340  2028 ?        Ss   Jan21   0:00 /usr/bin/dbus-daemon --system
rose      6972  0.0  0.0  24392   576 ?        S    Jan21   0:00 /usr/bin/dbus-launch --exit-with-session /usr/bin/ssh-agent -- gnome-session
rose      6973  0.0  0.0  20708  1776 ?        Ss   Jan21   0:00 /usr/bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session
rose      6993  0.0  0.0  19676  1636 ?        S    Jan21   0:00 /usr/bin/dbus-daemon --config-file=/etc/at-spi2/accessibility.conf --nofork --print-address 3
root      7458  0.0  0.0  24392   724 pts/0    S    Jan21   0:00 dbus-launch --autolaunch=c1c7bb398f2200724f41da4d00000057 --binary-syntax --close-stderr
root      7460  0.0  0.0  19636  1220 ?        Ss   Jan21   0:00 /usr/bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session
root     13557  0.0  0.0  24396   576 pts/2    S+   Jan21   0:00 dbus-launch --autolaunch=c1c7bb398f2200724f41da4d00000057 --binary-syntax --close-stderr
root     13562  0.0  0.0  19640   956 ?        Ss   Jan21   0:00 /usr/bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session
root@caiman:/root(39)# LC_ALL=C meld .bash_profile ~rose/.bash_profile

** (meld:5910): WARNING **: Couldn't connect to accessibility bus: Failed to connect to socket /tmp/dbus-8vGozcS5Ux: Connection refused


I have four dbus processes for root and everything is fine. If I use a ssh connection from "impala" to "thinkpad", I find:

root@thinkpad:/usr/local/portage/sci-visualization(177)# echo $DBUS_SESSION_BUS_ADDRESS

root@thinkpad:/usr/local/portage/sci-visualization(178)# ps waux | grep dbus |grep -v grep
message+  6370  0.0  0.0   3540  1268 ?        Ss    2012   0:01 /usr/bin/dbus-daemon --system
root     12881  0.0  0.0   2788   380 ?        Ss   Jan14   0:00 /usr/bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session
root     15469  0.0  0.0   4288   412 pts/0    S    Jan16   0:00 dbus-launch --autolaunch 7fdf8220502c3195e1e435c500015e1f --binary-syntax --close-stderr
root     15470  0.0  0.0   3688  1220 ?        Ss   Jan16   0:00 /usr/bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session
root@thinkpad:/usr/local/portage/sci-visualization(179)#  meld .bash_profile ~rose/.bash_profile

** (meld:1705): WARNING **: Couldn't connect to accessibility bus: Failed to connect to socket /tmp/dbus-8vGozcS5Ux: Connection refused
Traceback (most recent call last):
  File "/usr/bin/meld", line 154, in <module>
    main()
  File "/usr/bin/meld", line 146, in main
    new_window = app.parse_args(sys.argv[1:])
  File "/usr/lib/meld/meld/meldapp.py", line 206, in parse_args
    tab = open_paths(args, options.auto_compare, options.auto_merge)
  File "/usr/lib/meld/meld/meldwindow.py", line 696, in open_paths
    tab = self.append_diff(paths, auto_compare, auto_merge)
  File "/usr/lib/meld/meld/meldwindow.py", line 664, in append_diff
    return self.append_filediff(paths)
  File "/usr/lib/meld/meld/meldwindow.py", line 627, in append_filediff
    doc.set_files(files)
  File "/usr/lib/meld/meld/filediff.py", line 957, in set_files
    self.fileentry[i].prepend_history(absfile)
  File "/usr/lib/meld/meld/ui/historyentry.py", line 355, in prepend_history
    self.__gentry.prepend_text(text)
  File "/usr/lib/meld/meld/ui/historyentry.py", line 135, in prepend_text
    self.__insert_history_item(text, True)
  File "/usr/lib/meld/meld/ui/historyentry.py", line 130, in __insert_history_item
    self._save_history()
  File "/usr/lib/meld/meld/ui/historyentry.py", line 116, in _save_history
    self.__gconf_client.set_list(key, gconf.VALUE_STRING, gconf_items)
glib.GError: Configuration server couldn't be contacted: D-BUS error: Can't overwrite existing read-only value: Value for `/apps/gnome-settings/meld/history-fileentry' set in a read-only source at the front of your configuration path


At "lynx2" the error, described until Comment 2, disappeared after rebooting of "lynx2".

[Comment 7 Pacho Ramos 2013-01-29 21:53:41 UTC]

*** Bug 454536 has been marked as a duplicate of this bug. ***

[Comment 8 Doug Goldstein (RETIRED) 2013-01-29 23:44:31 UTC]

Having a similar issue with meld. Anytime I start it up with a command line argument of a path to a source tree, it fails to start with the following:


Traceback (most recent call last):
  File "/usr/bin/meld", line 154, in <module>
    main()
  File "/usr/bin/meld", line 146, in main
    new_window = app.parse_args(sys.argv[1:])
  File "/usr/lib64/meld/meld/meldapp.py", line 206, in parse_args
    tab = open_paths(args, options.auto_compare, options.auto_merge)
  File "/usr/lib64/meld/meld/meldwindow.py", line 696, in open_paths
    tab = self.append_diff(paths, auto_compare, auto_merge)
  File "/usr/lib64/meld/meld/meldwindow.py", line 660, in append_diff
    return self.append_dirdiff(paths, auto_compare)
  File "/usr/lib64/meld/meld/meldwindow.py", line 617, in append_dirdiff
    doc.set_locations(dirs)
  File "/usr/lib64/meld/meld/dirdiff.py", line 488, in set_locations
    self.fileentry[pane].prepend_history(loc)
  File "/usr/lib64/meld/meld/ui/historyentry.py", line 355, in prepend_history
    self.__gentry.prepend_text(text)
  File "/usr/lib64/meld/meld/ui/historyentry.py", line 135, in prepend_text
    self.__insert_history_item(text, True)
  File "/usr/lib64/meld/meld/ui/historyentry.py", line 130, in __insert_history_item
    self._save_history()
  File "/usr/lib64/meld/meld/ui/historyentry.py", line 116, in _save_history
    self.__gconf_client.set_list(key, gconf.VALUE_STRING, gconf_items)
glib.GError: Configuration server couldn't be contacted: D-BUS error: Unable to store a value at key '/apps/gnome-settings/meld/history-direntry', as the configuration server has no writable databases. There are some common causes of this problem: 1) your configuration path file /etc/gconf/2/path doesn't contain any databases or wasn't found 2) somehow we mistakenly created two gconfd processes 3) your operating system is misconfigured so NFS file locking doesn't work in your home directory or 4) your NFS client machine crashed and didn't properly notify the server on reboot that file locks should be dropped. If you have two gconfd processes (or had two at the time the second was launched), logging out, killing all copies of gconfd, and logging back in may help. If you have stale locks, remove ~/.gconf*/*lock. Perhaps the problem is that you attempted to use GConf from two machines at once, and ORBit still has its default configuration that prevents remote CORBA connections - put "ORBIIOPIPv4=1" in /etc/orbitrc. As always, check the user.* syslog for details on problems gconfd encountered. There can only be one gconfd per home directory, and it must own a lockfile in ~/.gconfd and also lockfiles in individual storage locations such as ~/.gconf


If run it without arguments and attempt to change any preferences while its running:

Traceback (most recent call last):
  File "/usr/lib64/meld/meld/preferences.py", line 175, in on_checkbutton_show_line_numbers_toggled
    self.prefs.show_line_numbers = check.get_active()
  File "/usr/lib64/meld/meld/util/prefs.py", line 121, in __setattr__
    setfunc("%s/%s" % (self._rootkey, attr), val)
glib.GError: Configuration server couldn't be contacted: D-BUS error: Unable to store a value at key '/apps/meld/show_line_numbers', as the configuration server has no writable databases. There are some common causes of this problem: 1) your configuration path file /etc/gconf/2/path doesn't contain any databases or wasn't found 2) somehow we mistakenly created two gconfd processes 3) your operating system is misconfigured so NFS file locking doesn't work in your home directory or 4) your NFS client machine crashed and didn't properly notify the server on reboot that file locks should be dropped. If you have two gconfd processes (or had two at the time the second was launched), logging out, killing all copies of gconfd, and logging back in may help. If you have stale locks, remove ~/.gconf*/*lock. Perhaps the problem is that you attempted to use GConf from two machines at once, and ORBit still has its default configuration that prevents remote CORBA connections - put "ORBIIOPIPv4=1" in /etc/orbitrc. As always, check the user.* syslog for details on problems gconfd encountered. There can only be one gconfd per home directory, and it must own a lockfile in ~/.gconfd and also lockfiles in individual storage locations such as ~/.gconf


This all started happening since I switched to GNOME 3.6. I'm using Cinnamon right now but I did try the normal GNOME Shell 3.6 and got the same results.

[Comment 9 Doug Goldstein (RETIRED) 2013-01-29 23:57:16 UTC]

Same issue with meld-1.6.1, which is considered stable by the upstream developer with GNOME 3.6.

[Comment 10 Joseph 2013-04-19 00:43:23 UTC]

I downgraded to meld-1.6.0 and this problem went away.

[Comment 11 Juergen Rose 2013-06-12 09:32:29 UTC]

It happens with meld-1.7.3 too:

glib.GError: Configuration server couldn't be contacted: D-BUS error: Can't overwrite existing read-only value: Value for `/apps/gnome-settings/meld/history-fileentry' set in a read-only source at the front of your configuration path
root@lynx:/root(20)# qlist -Iv meld
dev-util/meld-1.7.3

[Comment 12 Pacho Ramos 2013-06-12 09:50:16 UTC]

Before committing I tried to reproduce this but I couldn't. I tried to start meld on my cvs tree as user and as root. To become root I use "su -"

Can you give me your steps to reproduce with this last version?

[Comment 13 Juergen Rose 2013-06-12 11:18:35 UTC]

(In reply to Pacho Ramos from comment #12)
> Before committing I tried to reproduce this but I couldn't. I tried to start
> meld on my cvs tree as user and as root. To become root I use "su -"
> 
> Can you give me your steps to reproduce with this last version?

I was sitting at "impala" and had as user rose a ssh session to "lynx". Nobody was directly logged in at "lynx". In this ssh session as user rose at "lynx" I could use meld without problems. Then I became root at "lynx" (su -) and the isue happened.

[Comment 14 Pacho Ramos 2013-06-12 12:31:38 UTC]

Have you tried to use ssh -Y option?

[Comment 15 Juergen Rose 2013-06-12 15:39:58 UTC]

I am using only 'ssh -Y' ;-).

[Comment 16 Pacho Ramos 2013-06-12 22:31:33 UTC]

Have you tried suggestions posted in:
https://bugzilla.gnome.org/show_bug.cgi?id=666136#c0

to get gconfd properly running?

[Comment 17 Pacho Ramos 2013-07-27 11:36:31 UTC]

(In reply to Pacho Ramos from comment #16)
> Have you tried suggestions posted in:
> https://bugzilla.gnome.org/show_bug.cgi?id=666136#c0
> 
> to get gconfd properly running?

(I am really surprised with the amount of bugs you send us related with dbus activation problems that look to only affect you :/)