gnome-settings-daemon dconf to gconf plugin causes settings to be lost

[Margarita Manterola]

Impact:
Using dconf profiles can lead to gconf keys to be overwritten with wrong values, it's especially impact some desktop settings and compiz

Test Case:

$ gconftool --set /desktop/gnome/sound/event_sounds --type bool false
$ gconftool --get /desktop/gnome/sound/event_sounds
false

Then editing some file under /etc/dconf and running dconf update:

$ sudo vi /etc/dconf/db/site.d/screensaver
$ sudo dconf update
$ gconftool --get /desktop/gnome/sound/event_sounds
true

Regression potential:
Some of the gsettings could not be written back to gconf which could impact legacy applications which are still reading the gconf value

------

This was tested in a fresh installed precise machine, with the addition of dconf and a particular dconf configuration.

Settings set in gconf backend get overwritten when running 'dconf update'. This can be tested by changing any value in gconf to something different than the default:

$ gconftool --set /desktop/gnome/sound/event_sounds --type bool false
$ gconftool --get /desktop/gnome/sound/event_sounds
false
$ gconftool --set /apps/metacity/general/focus_mode --type string sloppy
$ gconftool --get /apps/metacity/general/focus_mode
sloppy

Then editing some file under /etc/dconf and running dconf update:

$ sudo vi /etc/dconf/db/site.d/screensaver
$ sudo dconf update
$ gconftool --get /desktop/gnome/sound/event_sounds
true
$ gconftool --get /apps/metacity/general/focus_mode
click

After talking about this with Ryan Lortie, he suggested disabling the gnome-settings-daemon plugin:

$ gsettings set org.gnome.settings-daemon.plugins.gconf active false
$ gconftool --set /desktop/gnome/sound/event_sounds --type bool false
$ gconftool --set /apps/metacity/general/focus_mode --type string sloppy

$ sudo vi /etc/dconf/db/site.d/screensaver
$ sudo dconf update
$ gconftool --get /desktop/gnome/sound/event_sounds
false
$ gconftool --get /apps/metacity/general/focus_mode
sloppy

It looks like the gconf plugin is overwriting all the settings with the defaults, thus losing anything the user had customized. It's quite likely that a number of other bugs "Compiz loses my settings" are actually caused by this plugin.

Also, as instructed by Ryan, I tried removing /usr/share/GConf/gsettings/wm-schemas.convert and re-enabling the plugin, and then it doesn't override any values that are related to the window manager but it does override the one in the example:

$ gsettings reset org.gnome.settings-daemon.plugins.gconf active
$ gsettings get org.gnome.settings-daemon.plugins.gconf active
true
$ gconftool --set /desktop/gnome/sound/event_sounds --type bool false
$ gconftool --set /apps/metacity/general/focus_mode --type string sloppy

$ sudo vi /etc/dconf/db/site.d/screensaver
$ sudo dconf update
$ gconftool --get /desktop/gnome/sound/event_sounds
true
$ gconftool --get /apps/metacity/general/focus_mode
sloppy

So, focus_mode didn't get overwritten while event_sounds did.

One possible solution is to remove the wm-schemas so that compiz settings don't get lost. A better (but probably harder) solution would be to fix the plugin so that it doesn't overwrite what the user sets. Maybe just remove the schemas that are being modified and stored in gconf for Precise.

I found out that to reproduce in a fresh installed precise machine, I had to set up some dconf files, then reboot, and then I could reproduce consistently as explained here. I'm attaching a bunch of dconf files. After unpacking, you need to run dconf update once to generate the db and then reboot. After that it should be reproducible.

[Margarita Manterola (marga-9)]

Sample configuration that allows to reproduce the bug.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Joel Ebel (jbebel)]

Under what conditions would the gconf plugin for gsettings daemon convert dconf settings into gconf? This is triggered by a dconf update while a user is logged in, which seems a rare use case under normal conditions. When is this plugin designed to operate normally, and could that other normal operation cause this same issue?

[Margarita Manterola (marga-9)]

This is my take on the issue from what I spoke with dsert earlier today:

There's a signal that dconf update emits when there are changes, so that monitoring stuff can find out about it. This plugin is one of the monitoring stuff.

The plugin is supposed to sync up settings from dconf to gconf for programs that are not aware of gconf. I think it's wrongly copying everything from dconf to gconf regardless of what the user had previously modified. What it _should_ do is only copy the stuff that comes from dconf but not what was modified directly in gconf. I suspect this is not possible.

[Allison Karlitskaya (desrt)]

The issue specifically:

'dconf update' emits a signal that says "everything has changed"

Meanwhile, we have the configuration migration stuff watching for changes and assuming that if there was a change in dconf it means that we should sync it up to gconf.

The trouble comes that "everything has changed" actually only means "everything has *potentially* changed".

One way we can work around this is the "change-event" signal on GSettings. It allows two things:

1) We can find out the difference between "everything changed" and "one thing changed".

2) We can return TRUE here to stop the signal from going further.

[Joel Ebel (jbebel)]

I'm pretty new to dconf, so I'm making some assumptions which may be incorrect. When dconf update is run as root, that only updates settings which are either mandatory or defaults system-wide. Neither of those changes should result in a change in the users home directory, and if a user wasn't logged in, nothing would happen currently. Because of that, I'm not sure that dconf update should be sending any signals which would trigger a gconf sync. At most, it should just re-read the system settings in order to accept the new default or mandatory settings. Even if that doesn't happen, on next login, they will be re-read, right?

Unrelated, I'm surprised to find dconf defaults that don't match up with gconf defaults. Like the metacity button_layout dconf default puts the buttons back on the right. This was the primary reason I noticed this was all happening in the first place. when dconf update ran, it updated the gconf setting for the button layout and moved the buttons back the the right.

[Joel Ebel (jbebel)]

This also exposes something else, which might be better as a separate bug. wm-schemas.convert tries to convert metacity keybindings from dconf to gconf. Unfortunately the types are different, so anything accepted by dconf probably won't actually work once it's written to gconf. This was exposed because a dconf update wound up writing all these keybindings into gconf. For example, dconf has org.gnome.desktop.wm.keybindings switch-windows as ['<Alt>Tab'] which is an array of strings. However, metacity expects this to be just the string '<Alt>Tab'. When the gconf conversion happens, it seems to actually convert the key to a list of strings in gconf, and metacity stops supporting Alt-Tab.

[Margarita Manterola (marga-9)]

Hi,

I have prepared and tested a small patch that fixes this issue. What the patch does is not update any keys when dconf emits the "everything changed" signal. To do this, it connects to the "event_change" signal and checks if the number of keys is 0, and returns TRUE in that case to prevent the "changed" signal from executing.

I have tested that the dconf update call does not trigger the overwriting of keys, but that when using dconf-editor to edit keys, these values are copied over to gconf.

[Allison Karlitskaya (desrt)]

Functionally, the patch looks pretty good to me. Thanks for the attention to detail with respect to the signal disconnection.

One small detail is that the function you introduce should be marked 'static' (since it is not used outside of the current file). Otherwise, everything else looks fine. A comment about why this function exists is probably also reasonable since it's non-obvious from just looking at it.

[Margarita Manterola (marga-9)]

Joel, regarding the Alt-Tab thing, it's reported in: https://bugs.launchpad.net/ubuntu/+source/unity-2d/+bug/963125

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "Patch to the plugin" of this bug report has been identified as being a patch. The ubuntu-reviewers team has been subscribed to the bug report so that they can review the patch. In the event that this is in fact not a patch you can resolve this situation by removing the tag 'patch' from the bug report and editing the attachment so that it is not flagged as a patch. Additionally, if you are member of the ubuntu-reviewers team please also unsubscribe the team from this bug report.

[This is an automated message performed by a Launchpad user owned by Brian Murray. Please contact him regarding any issues with the action taken in this bug report.]

[Margarita Manterola (marga-9)]

I'm attaching a revised version, taking into account Ryan's comments.

[Allison Karlitskaya (desrt)]

Ready to go, imho.

Marga: one tiny point that I missed the first time around. GObject signals are nominally written like "signal-name" rather than "signal_name". Your patch is fine as-is -- it's mostly a matter of style in this case.

[Joel Ebel (jbebel)]

I added my comments to bug 963125 regarding the dconf array keybindings being converted to lists in gconf, where metacity expects strings.

[Steve Langasek (vorlon)]

Hello Margarita, or anyone else affected,

Accepted gnome-settings-daemon into precise-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/gnome-settings-daemon/3.4.2-0ubuntu0.5 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please change the bug tag from verification-needed to verification-done. If it does not, change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[Joel Ebel (jbebel)]

I can confirm that the new package does prevent settings in dconf from propagating into gconf on a dconf update after the package is installed and the user is logged out and back in. I haven't used the new package long enough to identify if there are any regressions, but it does seem to fix this bug.

[Scott Kitterman (kitterman)]

The verification of this Stable Release Update has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regresssions.

[Launchpad Janitor (janitor)]

This bug was fixed in the package gnome-settings-daemon - 3.4.2-0ubuntu0.5

---------------
gnome-settings-daemon (3.4.2-0ubuntu0.5) precise-proposed; urgency=low

  * debian/patches/dont_overwrite_gconf_keys.patch:
    - don't trigger the gsettings->gconf keys conversion on "dconf update"
      runs, thanks Margarita Manterola for the fix and testing
      (lp: #1071950)
 -- Sebastien Bacher <email address hidden> Tue, 30 Oct 2012 13:28:05 +0100

[Margarita Manterola (marga-9)]

Thanks Sebastian, Steve, and everybody else involved in getting this fixed in precise!

[Lorant Nemeth (loci)]

Any idea when the fix is going to be available in Quantal and if it's already in Raring?

[Rolf Leggewie (r0lf)]

quantal has seen the end of its life and is no longer receiving any updates. Marking the quantal task for this ticket as "Won't Fix".