After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 659835 - Configuration server couldn't be contacted: D-BUS error: Method "Set" with signature "s(ii)" on interface "org.gnome.GConf.Database" doesn't exist
Configuration server couldn't be contacted: D-BUS error: Method "Set" with si...
Status: RESOLVED FIXED
Product: GConf
Classification: Deprecated
Component: gconf
3.1.x
Other Linux
: Normal normal
: ---
Assigned To: GConf Maintainers
GConf Maintainers
: 659917 660142 661419 (view as bug list)
Depends on:
Blocks: 659841
 
 
Reported: 2011-09-22 15:41 UTC by Pedro Villavicencio
Modified: 2011-11-08 15:20 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
gconf-dbus: On SIGHUP, do not recreate databases but reload the sources (6.30 KB, patch)
2011-10-17 18:13 UTC, Vincent Untz
none Details | Review
gconf-dbus: Do not drop old databases that have clients listening to it (1.06 KB, patch)
2011-10-17 18:13 UTC, Vincent Untz
none Details | Review
gconf-dbus: Emit a Bye dbus signal when dropping a database (4.52 KB, patch)
2011-10-17 18:13 UTC, Vincent Untz
none Details | Review
gconf-dbus: Fix leaks (828 bytes, patch)
2011-10-17 18:13 UTC, Vincent Untz
none Details | Review

Description Pedro Villavicencio 2011-09-22 15:41:50 UTC
this report has been filed here:

https://bugs.launchpad.net/ubuntu/+source/gconf/+bug/848198

"Since updating to 3.91, evolution and other apps like gnome-tweak-tool gives a gconf error message about once or twice a day. messages are:"

Configuration server couldn't be contacted: D-BUS error: Method "Set" with signature "s(ii)" on interface "org.gnome.GConf.Database" doesn't exist 

and evo is showing a dialog with

https://bugs.launchpad.net/ubuntu/+source/gconf/+bug/848198/+attachment/2392954/+files/Screenshot%20at%202011-09-12%2015%3A26%3A01.png
Comment 1 Christian Persch 2011-09-22 16:46:47 UTC
There is no version 3.91; did you mean gconf 3.1.92 ?

Just to be clear: this is an intermittent error, not a persistent one, right?

Wchih gconf version was in ubuntu prior to this version? The only code change from 3.1.90 to 3.1.92 is from bug 655954 which I don't think could cause this.
Comment 2 Pedro Villavicencio 2011-09-22 17:08:20 UTC
right, the version is 3.1.92-0ubuntu1 ; and the error seems to be intermittent yes, and prior to 3.1.92 we had 3.1.90. is there any way we can help to debug this? Thanks for the fast response!.
Comment 3 Sebastien Bacher 2011-09-22 17:33:21 UTC
the issue is not really new, it might be there since gconf switched to dbus, it seems to happen after package upgrades, could be due to the sighup sent to gconf service, though sending a sighup doesn't trigger the issue so it's not a direct 1-1 thing
Comment 4 Christian Persch 2011-09-22 17:45:40 UTC
I guess you could use dbus-monitor to log the traffic between gconfd and one of the apps, and look what was exchanged when the failure occurs.

Note also bug 656867 which looks similar. But then you seem to have had no problem prior to 3.1.90...
Comment 5 Andreas Proschofsky 2011-09-28 08:20:58 UTC
Getting lots of those errors too (too make it worse: as a series of pretty annoying pop-ups), and this definitely was caused by the switch to dbus. And as this is now the default backend the severity of this bug should be raised IMHO.

GConf error: Configuration server couldn't be contacted: D-BUS error: Method "LookupExtended" with signature "ssb" on interface "org.gnome.GConf.Database" doesn't exist
Comment 6 Ross Burton 2011-10-04 12:31:32 UTC
*** Bug 660142 has been marked as a duplicate of this bug. ***
Comment 7 Ross Burton 2011-10-04 12:33:09 UTC
It looks like packaging scripts (my reference is Debian, I expect other distros are the same) will send a SIGHUP after updating the schemas to tell gconf2 to re-read the database.

I suspect that the signal handler is in a #if ORBIT clause somewhere, so isn't registered. This will mean that the default handler for SIGHUP will be executed, which is to terminate the process.
Comment 8 Ian B. MacDonald 2011-10-04 12:50:50 UTC
This is exactly what I figured. Probably something minor that could be handled cleanly for the user.  I expect rpm package managers implement similar functionality.
Comment 9 Vincent Untz 2011-10-13 17:21:52 UTC
I'm not convinced this is related to a SIGHUP following package upgrades. I mean, what happens if the process terminates? Then it will be restarted next time a client calls gconf.

And as far as I can tell, when I can see this issue, gconf is running.
Comment 10 Ray Strode [halfline] 2011-10-13 17:32:17 UTC
one pitfall people fall into with libdbus is if you don't call dbus_connection_register_object_path before dbus_bus_request_name then it's possible to get errors like the above if the process is activated (say following the proposed SIGHUP issue).

I haven't looked at the code to see if gconfd has fallen into this trap, but a few years ago I remember having to fix up a couple different projects that got this wrong.
Comment 11 Vincent Untz 2011-10-17 08:45:09 UTC
Okay, I think I found the issue:

 - we run periodic_cleanup_timeout() every 30 seconds
 - on SIGHUP, or if there was no access to a gconf database in the last 20 minutes, we shutdown databases (on SIGHUP, we also restart the default one)
 - dbus-wise, this means that the object path of the database will change (for instance, the default database usually starts with the /org/gnome/GConf/Database/0 object path and on SIGHUP, it will get /org/gnome/GConf/Database/1)
 - on the client side, we have no idea this is happening, and so we try to talk to /org/gnome/GConf/Database/0, but fail

One idea to fix this would be to reuse the basename of the path ("0") for a database when restarting it. So on SIGHUP, the default database would stay on /org/gnome/GConf/Database/0 instead of moving to /org/gnome/GConf/Database/1.

However, that won't work well with shutting down a database if it hasn't been accessed in the last 20 minutes: the clients won't know it's shut down, and the database will not be restarted automatically.

So an alternative is to add some more dbus communication: a database can send a "Good bye" message when it's shutting down, and the clients can then know if they want to restart it.

Any opinion?
Comment 12 Ross Burton 2011-10-17 13:00:38 UTC
Heh, good catch Vincent.

I'd say for restarting the path should be kept, but on a shutdown there should be a signal.
Comment 13 Vincent Untz 2011-10-17 18:13:30 UTC
Created attachment 199238 [details] [review]
gconf-dbus: On SIGHUP, do not recreate databases but reload the sources

When we destroy and recreate a database, the object path associated to
it on dbus changes. This is bad as clients do not know about the object
path change, and therefore fail.

Instead of destroying and recreating the databases, we simply reload the
sources for this database. This achieves the same result, without
changing the object path.

Note that for the corba backend, we still use the old way as simply
reloading the sources might not work -- the sources are used in
corba-specific code.
Comment 14 Vincent Untz 2011-10-17 18:13:35 UTC
Created attachment 199239 [details] [review]
gconf-dbus: Do not drop old databases that have clients listening to it

This would be bad as clients would get lost when the object path of this
dropped database disappears.
Comment 15 Vincent Untz 2011-10-17 18:13:39 UTC
Created attachment 199240 [details] [review]
gconf-dbus: Emit a Bye dbus signal when dropping a database

This enables clients to know the database got dropped, and to stop
referencing the object path of this database. The clients will
eventually cause the re-creation of this database when they'll need it.
Comment 16 Vincent Untz 2011-10-17 18:13:45 UTC
Created attachment 199241 [details] [review]
gconf-dbus: Fix leaks
Comment 17 Vincent Untz 2011-10-17 18:16:13 UTC
This set of patches seems to fix the issue for me. The first two are the critical ones; I was not really able to test the third one (Bye signal), and the fourth one is unrelated -- just something I happened to notice.

I'd appreciate testing, since it's easy to break things in fun ways when touching core parts of gconf like that.
Comment 18 Michael Gratton 2011-10-18 23:41:03 UTC
*** Bug 661419 has been marked as a duplicate of this bug. ***
Comment 19 Andrés G. Aragoneses (IRC: knocte) 2011-10-19 17:34:08 UTC
*** Bug 662223 has been marked as a duplicate of this bug. ***
Comment 20 Vincent Untz 2011-10-21 14:34:56 UTC
If there's nobody testing those patches, maybe we should just go ahead and merge the patches and do a 3.3.1 release next week?
Comment 21 Ian B. MacDonald 2011-10-21 14:39:31 UTC
I'll test them on current 3.2.1-0ubuntu1.  The issue is 100% reproducible on dpkg -i of new packages.
Comment 22 Ian B. MacDonald 2011-10-21 14:46:09 UTC
Not sure about this message.. but I will build anyways

/usr/src/gconf-3.2.0# cat /home/imac/Desktop/patches/gconf-dbus-* | patch -p1
patching file gconf/gconfd.c
Hunk #1 succeeded at 1268 (offset -12 lines).
patching file gconf/gconf-database-dbus.c
patching file gconf/gconf-dbus-utils.h
patching file gconf/gconf-dbus.c
patching file gconf/gconfd-dbus.c
patching file gconf/gconfd-dbus.h
patching file gconf/gconf-database-dbus.c
patching file gconf/gconf-database.c
patching file gconf/gconf-database.h
patching file gconf/gconfd.c
Hunk #6 succeeded at 1335 (offset 4 lines).
patch unexpectedly ends in middle of line
Comment 23 Michael Gratton 2011-10-21 22:52:41 UTC
A couple of people have reported on Launchpad that the patches fix the problem.

https://bugs.launchpad.net/bugs/848198
Comment 24 Ian B. MacDonald 2011-10-23 14:05:58 UTC
Resolves all my repeatable use cases below, thanks.

1) Re-installing evolution packages with evolution running
2) Re-installing gnome-settings-daemon with evolution running
Comment 25 Ross Burton 2011-10-23 19:15:48 UTC
I was speaking to Rob Bradford about this earlier and he thinks that instead of changing the periodic cleanup behaviour we take the opinion that the cleanup was because there isn't a session scope in ORBit and just drop those codepaths.

I'm of the opinion that whilst this is probably true we have a tested patch for this approach.
Comment 26 Vincent Untz 2011-10-24 13:45:22 UTC
(In reply to comment #25)
> I was speaking to Rob Bradford about this earlier and he thinks that instead of
> changing the periodic cleanup behaviour we take the opinion that the cleanup
> was because there isn't a session scope in ORBit and just drop those codepaths.

Purely dropping the cleanup means that we'll keep in memory all databases that get opened, even when they're not needed anymore. An example is that when you open gconf-editor, you get a db for the default values and another one for the mandatory values. And we don't need to keep those in memory for the rest of the session.

That being said, that could be considered as a corner case, as most gconf users just use the default database... So maybe it's not that much of an issue.
Comment 27 Ross Burton 2011-10-24 16:20:38 UTC
Committed to git, expect 3.2.1 shortly.
Comment 28 Jasper St. Pierre (not reading bugmail) 2011-10-24 19:16:42 UTC
*** Bug 659917 has been marked as a duplicate of this bug. ***
Comment 29 Jasper St. Pierre (not reading bugmail) 2011-10-24 19:20:08 UTC
Review of attachment 199238 [details] [review]:

::: gconf/gconf-database.c
@@ +800,3 @@
+#ifdef HAVE_CORBA
+      /* this function should only be used when creating the db with the corba
+       * backend */

Is it me or is this section backwards from what the comment says?
Comment 30 Ross Burton 2011-10-26 12:51:03 UTC
Erm, yes.  Good catch.
Comment 31 Ross Burton 2011-10-26 15:42:50 UTC
Committed.