2

My gsettings database has many entries that are duplicated or triplicated. Some are "normal" single entries.

$ gsettings --schemadir /usr/share/glib-2.0/schemas list-recursively | grep button-power
org.gnome.settings-daemon.plugins.power button-power 'interactive'
org.gnome.settings-daemon.plugins.power button-power 'interactive'

$ gsettings list-recursively | grep sudoku-difficulty
org.gnome.sudoku print-multiple-sudoku-difficulty 'easy'

$ gsettings list-recursively | grep print-wrap-mode
org.gnome.gedit.preferences.print print-wrap-mode 'word'
org.gnome.gedit.preferences.print print-wrap-mode 'word'
org.gnome.gedit.preferences.print print-wrap-mode 'word'

dconf dump and dconf load are not effective

The utility dconf dump doesn't show duplicate entries:

$ dconf dump /org/gnome/settings-daemon/plugins/power/
[/]
idle-dim=false
lid-close-battery-action='nothing'
critical-battery-action='shutdown'
lid-close-ac-action='nothing'

Running dconf dump of single entries to file and import same file using dconf load doesn't get rid of duplicate entries:

$ gsettings list-recursively | grep lid-close-battery
org.gnome.settings-daemon.plugins.power lid-close-battery-action 'nothing'
org.gnome.settings-daemon.plugins.power lid-close-battery-action 'nothing'

$ dconf dump /org/gnome/settings-daemon/plugins/power/ > dconf-lid-battery.txt

$ dconf load /org/gnome/settings-daemon/plugins/power/ < dconf-lid-battery.txt

$ gsettings list-recursively | grep lid-close-battery
org.gnome.settings-daemon.plugins.power lid-close-battery-action 'nothing'
org.gnome.settings-daemon.plugins.power lid-close-battery-action 'nothing'

Might be a bug?

Appears to be a bug:

Based on bug reports it could be these three areas:

$ gsettings get org.freedesktop.ibus.general dconf-preserve-name-prefixes
['/desktop/ibus/engine/pinyin', '/desktop/ibus/engine/bopomofo', '/desktop/ibus/engine/hangul']

Replies to comments

Here are file and directory names of /etc/dconf:

$ tree /etc/dconf/
/etc/dconf/
├── db
│   ├── ibus
│   └── ibus.d
│       └── 00-upstream-settings
└── profile
    └── ibus

3 directories, 3 files

Two of three files are dated from 2016 (Ubuntu 16.04 development time):

-rw-r--r-- 1 root root 3163 Oct  1 16:51 /etc/dconf/db/ibus
-rw-r--r-- 1 root root 1978 Jan 19  2016 00-upstream-settings
-rw-r--r-- 1 root root   28 Jan 19  2016 /etc/dconf/profile/ibus
15
  • if you remove an entry does that remove both? If not you could create a sorted list for gsettings list-recursively and move the dupes to a 2nd file and use that file to a remove.
    – Rinzwind
    Nov 5, 2018 at 15:57
  • @Rinzwind I've googled for an hour and still haven't figured out how to delete a gsettings / dconf database entry. Do you have a link to such a function? Nov 5, 2018 at 17:34
  • It is gsettings reset <key-path> ;-) oh and I think I might have found your problem: you probably have 2 schema definitions.
    – Rinzwind
    Nov 5, 2018 at 18:03
  • @Rinzwind Unfortunately reset simply resets to installation default. It doesn't delete or remove the key-pair. After running for lid-close-battery-action above it changed the key from nothing to suspend. I will search for how I might have 2 or 3 schemas setup though. Nov 5, 2018 at 21:05
  • @WinEunuuchs2Unix , first time to see such gsettings behavior. (1)Check /etc/dconf/profile/ contents for active databases. (2)Use DBus monitor or d-feet to monitor replies dconf daemon while a gsettings query (if duplication exists in data passed). (3) dconf dump to backup user settings, logout, switch to console, login root (or superuser with sudo), move dconf user-db & system-db if there one to backup them also /usr/share/glib-2.0/schemas/gschemas.compiled, run glib-compile-schemas /usr/share/glib-2.0/schemas to compile new schema, logout then login through GUI & dconf load settings
    – user.dz
    Dec 27, 2019 at 8:49

0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.