GSettings/dconf reports incorrect values on setting change
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Snapcraft |
Fix Released
|
Medium
|
Marcus Tomlinson |
Bug Description
When reading a gsetting value from a change signal, this value is not updated correctly. This can be demonstrated with the following snap: https:/
The script in the snap uses "gsettings monitor" to report changes to the gsettings values
When the script is run outside of a snap it outputs the following values:
'fr'
active-language: 'en'
'en'
active-language: 'de'
'de'
active-language: 'fr'
'fr'
However when run in a snap it outputs:
'fr'
active-language: 'fr'
'en'
active-language: 'fr'
'de'
active-language: 'fr'
'fr'
Explicit requests to read a key from gsettings results in the correct value being returned, but the changes reported by gsettings are never updated.
The same behaviour can be replicated using "dconf watch" instead of "gsettings monitor", suggesting the underlying problem is with dconf usage within snaps. I've noticed that dconf appears to use both the user's real dconf settings in ~/.config/
Also, there are no apparmor or seccomp denials reported in the system log when running this snap.
description: | updated |
Changed in snapd: | |
assignee: | nobody → Marcus Tomlinson (marcustomlinson) |
Changed in snapd: | |
assignee: | Marcus Tomlinson (marcustomlinson) → James Henstridge (jamesh) |
Changed in snapd: | |
assignee: | James Henstridge (jamesh) → Marcus Tomlinson (marcustomlinson) |
status: | Triaged → In Progress |
affects: | snapd → snapcraft |
summary: |
- GSettings/dconf reports incorrect values on setting change under - confinement + GSettings/dconf reports incorrect values on setting change |
Changed in snapcraft: | |
status: | In Progress → Fix Committed |
Changed in snapcraft: | |
status: | Fix Committed → Fix Released |
I have a feeling this has to do with the shm file in the xdg runtime directory. This is how the service signals to clients that the database has changed and needs to be re-opened (otherwise they will continue to use the old copy). If this is not being shared correctly between the snap and the outside work (different XDG_RUNTIME_DIR setting?) then dconf isn't going to report changes properly.