GNOME Bugzilla – Bug 641768
dconf gsettings backend silently drops writes if it can't talk to dbus
Last modified: 2011-08-16 18:19:05 UTC
If the dconf gsettings backend can't connect to the session bus, it just fails silently. Eg, if you run the gsettings tool from a vt, then it won't be able to find a running bus, and it won't be able to launch a new bus (because apparently dbus-launch requires X to be running). But it doesn't give any error, it just pretends to have set the key.
Would a g_warning() on failure to connect to D-Bus be good enough?
Well... it would be better than what's there now. But there are probably other situations where the app may want to know, programmatically, that things are failing.
I intentionally left that ability out since I've noticed that applications tend to check error codes if one is available via the API -- and in this case, it's better that they do not (since we would get about 100 weird/broken copy-pasted implementations of popping up a Gtk error dialog about the problem). Most applications can not (and should not) meaningfully notify the user about something that is almost certainly an installation/distribution error. That said, some other out-of-band notification could be extremely helpful here. The annoying irony, however, is that I imagine most such out-of-band notifications would use D-Bus in some way or another... Do you have a better suggestion about how this could be handled in the general (ie: not commandline) case for normal apps?
If GSettingsBackend had an equivalent of g_vfs_is_active(), then the dconf backend could recuse itself if there wasn't already a session bus running, and then you'd get a memory backend, with associated g_warning. And even if you didn't see the warning, it might still be (more) obvious that something's wrong, since you'd get the default values for everything.
Interesting. We could just have the dconf backend fail to register itself if it can't get on DBus. The problem with that, of course, is that it requires attempting to connect to D-Bus... We could check for an environment variable and, if set, assume that D-Bus is present. It also begs another question: by the same logic, don't we want to attempt to guard against cases where the dconf service can't be started for one reason or another? We can't really do that... Also: dconf is perfectly fine to use without the session bus -- you just can't write. Should we really remove your ability to read your settings just because D-Bus can't be contacted? One more thing: I'm not sure it's possible to have a global 'is dconf available' function since it's possible to configure a dconf profile such that it doesn't require access to the session bus (ie: only system-level databases in use).
How about just having the gsettings tool do a get() after it does the sync(), and if the value wasn't updated, print an error and exit(1).
Created attachment 183115 [details] [review] gsettings-tool: warn if setting a value fails warning: breaks string freeze...
Attachment 183115 [details] pushed as ea57fef - gsettings-tool: warn if setting a value fails
oops, I didn't actually mean to commit this. So... uh... revert it if you don't like it. :-)
(In reply to comment #9) > oops, I didn't actually mean to commit this. So... uh... revert it if you don't > like it. :-) You wish is my command: http://git.gnome.org/browse/glib/commit/?id=eabad1923e7b0f133f8f38e57601a97521e38cfe attachment 183115 [details] [review] makes gsettings fail any time the user tries to set a key to the same value it already has. This breaks gdm dist-check among other things. Maybe the backend should keep a state variable "in_read_only_mode" if they couldn't get on the bus or something and post a g_warning() if the state variable is true and some write is attempted?
Created attachment 189352 [details] [review] gsettings-tool: warn if setting a value fails change the check to "if (!g_variant_equal (stored, new))" rather than "if (g_variant_equal (stored, existing))"
Review of attachment 189352 [details] [review]: This seems more reasonable, but will cause spurious messages in sort of pathological cases (think multiple gsettings calls in parallel) Any reason not to track the dbus case specifically in the backend?
I'm just going to g_warning() from the dconf backend when a write fails for any reason. This should only be in "your install is broken" type of cases anyway...
Okay. Now you get something like this: $ gsettings set org.gnome.shell.clock show-date true ** (process:4548): WARNING **: Command line `dbus-launch --autolaunch=63d8da7f109ce322e1d478de00000008 --binary-syntax --close-stderr' exited with non-zero exit status 1: Autolaunch error: X11 initialization failed.\n or this: $ gsettings set org.gnome.shell.clock show-date true ** (process:4507): WARNING **: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name ca.desrt.dconf was not provided by any .service files which seems pretty reasonable to me.