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
Community
  • 1
WinEunuuchs2Unix
  • 102,282
  • 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 05 '18 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? – WinEunuuchs2Unix Nov 05 '18 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 05 '18 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. – WinEunuuchs2Unix Nov 05 '18 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 '19 at 08:49
  • The process in (3) is just to recreate dconf user-db from scratch. You may try create new user to check . If (2) showing no duplicate in data, then it could be a bug in gsettings itself (dconf is out of the problem). – user.dz Dec 27 '19 at 08:52
  • @user.dz Thanks for looking at my problem. I've updated answer with suggestion (1). It appears to be a skeleton and other databases need to be checked? – WinEunuuchs2Unix Dec 27 '19 at 14:26
  • Could you share content of /etc/dconf/profile/ibus there you find the active dconf databases. My answer here https://askubuntu.com/a/417330/26246 have an example. See if you can go through option (3) – user.dz Dec 28 '19 at 21:54
  • @user.dz There are two entries from $ cat /etc/dconf/profile/ibus first: user-db:user and second: system-db:ibus – WinEunuuchs2Unix Dec 28 '19 at 22:02
  • So your user-db is ~/.config/dconf/user and system-db is /etc/dconf/db/ibus for option (3) – user.dz Dec 28 '19 at 22:25
  • @user.dz Your answer doesn't contain an "option (3)" There are two sections. In the second section there are number points 1 & 2 but no 3. In the second section there are bullet points and the third bullet point reads Schema Files: Relation between schema id & schema path (.gschema.xml) Is the Schema analysis what you mean by "option (3)"? – WinEunuuchs2Unix Dec 28 '19 at 22:32
  • Excuse me that I wasn't clear. I meant (3) of my comment here https://askubuntu.com/questions/1090244/dconf-database-how-to-remove-duplicate-triplicates?noredirect=1#comment2009577_1090244 to create DB from scratch. – user.dz Dec 28 '19 at 22:37
  • @user.dz Ahh (light goes on) now I get it. Sorry for being a bit daft. I'm in the middle of my first Pyhton project with tkinter resizable canvas, grids, x-scrollbars, y-scrollbars, etc. It's my first exposure transitioning from CLI & procedural bash language to GUI and OOPS so my brain is all mushy :( I will recreate DB from scratch and report back when I get a break from this inaugural Python project (if I'm still sane). – WinEunuuchs2Unix Dec 28 '19 at 22:43
  • @user.dz This might be the cause: gsettings get org.freedesktop.ibus.general dconf-preserve-name-prefixes returns three sets: ['/desktop/ibus/engine/pinyin', '/desktop/ibus/engine/bopomofo', '/desktop/ibus/engine/hangul'] and I found references to prefixes in a closed Red Hat bug report today. – WinEunuuchs2Unix Jan 05 '20 at 18:12
  • @WinEunuuchs2Unix I have seen similar case to this but it wasn't same, I couldn't get a full grasp of it. It was with Compiz settings: that has separate dconf path for each profile but same gsettings id. gsettings query requires using both id & path. Good, I could find that post: https://askubuntu.com/q/320674/26246 . It is called a "relocatable schema". – user.dz Jan 27 '20 at 13:55

0 Answers0