DCONF(7)

📦
version 51.0 · 14 versions
, in arch rolling

💅 dconf(7) — Conventions and miscellaneous

okay so bestie, welcome to dconf(7), the section-7 page about conventions and miscellaneous stuff, and it's literally all about dconf. grab a snack, we're getting into it 🍓

✨ NAME ✨

dconf — a configuration system. that's it, that's the vibe. a whole config system, periodt.

🌸 DESCRIPTION 🌸

okay so dconf is a simple key/value storage system that is heavily optimised for reading. and when I say heavily I mean it. this makes it, like, the ideal system for storing user preferences — and the reason is genuinely iconic: those preferences get read 1000s of times for every one time the user changes one. so yeah, it was created with this usecase in mind. main character energy from day one 👑

all preferences are stored in a single large binary file. layering of preferences is possible using multiple files (ie: for site defaults). lock-down is also supported. and the binary file for the defaults can optionally be compiled from a set of plain text keyfiles. cute, flexible, no notes.

dconf has a partial client/server architecture. it uses D-Bus. the server is only involved in writes (and is not activated in the user session until the user actually modifies a preference). the service is stateless and can exit freely at any time — which means it's robust against crashes, slay. the list of paths that each process is watching is stored within the D-Bus daemon itself (as D-Bus signal match rules). iconique.

reads are performed by direct access (via mmap) to the on-disk database, which is essentially a hashtable. because of this, dconf reads typically involve zero system calls and are comparable to a hashtable lookup in terms of speed. practically speaking, in simple non-layered setups, dconf is less than 10 times slower than GHashTable. zero syscalls!! we love to see it 💖

writes are assumed only to happen in response to explicit user interaction (like clicking on a checkbox in a preferences dialog) and are therefore not optimised at all. and on some file systems, dconf-service will call fsync() for every write, which can introduce a latency of up to 100ms. 💀 but don't panic — this latency is hidden by the client libraries through a clever "fast" mechanism that records the outstanding changes locally (so they can be read back immediately) until the service signals that a write has completed. the client libs are carrying the whole team tbh.

to overcome mmap issues when the binary database is on NFS, dconf places a binary database in XDG_RUNTIME_DIR (which is guaranteed to be local, but non-persistent) and synchronizes it automatically with the one in the user's home directory. bestie said "NFS who? never heard of her" 🙈

🦋 PROFILES 🦋

a profile is a list of configuration databases that dconf consults to find the value for a key. the user's personal database always takes the highest priority, followed by the system databases in the order prescribed by the profile. priority order is not up for debate, she's booked and busy.

on startup, dconf consults the DCONF_PROFILE environment variable. if set, dconf will attempt to open the named profile, aborting if that fails. (yes, aborting. dramatic but fair.) if the environment variable is not set, it will attempt to open the profile named "user" and if that fails, it will fall back to an internal hard-wired configuration.

dconf stores its profiles in text files. DCONF_PROFILE can specify a relative path to a file in /etc/dconf/profile/, or an absolute path (such as in a user's home directory). the profile name can only use alphanumeric characters or '_'. that's the whole dress code, no exceptions 💅

a profile file might look like the following:

user-db:user
system-db:local
system-db:site

each line in a profile specifies one dconf database. the first line indicates the database used to write changes, and the remaining lines indicate read-only databases. (the first line should specify a user-db or service-db, so that users can actually make configuration changes. like, otherwise what are we even doing here.)

the line types, bestie

  • a "user-db" line specifies a user database. these databases are found in $XDG_CONFIG_HOME/dconf/. the name of the file to open in that directory is exactly as it is written in the profile. this file is expected to be in the binary dconf database format.
important caveat moment 🚨 note that XDG_CONFIG_HOME cannot be set/modified per terminal or session, because then the writer and reader would be working on different DBs (the writer is started by DBus and cannot see that variable). so like, don't do that. the writer can't see it. it's not a vibe.
  • a "service-db" line instructs dconf to place the binary database file for the user database in XDG_RUNTIME_DIR. since this location is not persistent, the rest of the line instructs dconf how to store the database persistently. a typical line is service-db:keyfile/user, which tells dconf to synchronize the binary database with a plain text keyfile in $XDG_CONFIG_HOME/dconf/user.txt. the synchronization is bi-directional. both ways, always, that's the relationship 🫶
  • a "system-db" line specifies a system database. these databases are found in /etc/dconf/db/. again, the name of the file to open in that directory is exactly as it is written in the profile and the file is expected to be in the dconf database format.

if the DCONF_PROFILE environment variable is unset and the "user" profile can not be opened, then the effect is as if the profile was specified by this file:

user-db:user

that is, the user's personal database is consulted and there are no system settings. just you and your own little database against the world ✨

🎀 KEY FILES 🎀

to facilitate system configuration with a text editor, dconf can populate databases from plain text keyfiles. for any given system database, keyfiles can be placed into the /etc/dconf/db/database.d/ directory. the keyfiles contain groups of settings as follows:

# Some useful default settings for our site

[system/proxy/http]
host='172.16.0.1'
enabled=true

[org/gnome/desktop/background]
picture-uri='file:///usr/local/rupert-corp/company-wallpaper.jpeg'

after changing keyfiles, the database needs to be updated with the dconf(1) tool. don't forget the update step bestie, the keyfiles alone aren't gonna do it 🔥

🔒 LOCKS 🔒

system databases can contain 'locks' for keys. if a lock for a particular key or subpath is installed into a database then no database listed above that one in the profile will be able to modify any of the affected settings. this can be used to enforce mandatory settings. it's giving "this is not a suggestion, this is policy" 👑

to add locks to a database, place text files in the /etc/dconf/db/database.d/locks directory, where database is the name of a system database, as specified in the profile. the files contain list of keys to lock, on per line. lines starting with a # are ignored. here is an example:

# prevent changes to the company wallpaper
/org/gnome/desktop/background/picture-uri

after changing locks, the database needs to be updated with the dconf(1) tool. again with the update step. it's a whole thing, but it's the thing.

🌈 PORTABILITY 🌈

dconf mostly targets Free Software operating systems. it will theoretically run on Mac OS but there isn't much point to that (since Mac OS applications want to store preferences in plist files). no cap, it's just not the move.

it is not possible to use dconf on Windows because of the inability to rename over a file that's still in use (which is what the dconf-service does on every write). literally cannot. blocked by the OS itself 😭

⭐ API STABILITY ⭐

the dconf API is not particularly friendly, and is not guaranteed to be stable. because of this and the lack of portability, you almost certainly want to use some sort of wrapper API around it. (almost certainly. like, please.)

the wrapper API used by GTK+ and GNOME applications is GSettings[1], which is included as part of GLib. GSettings has backends for Windows (using the registry) and Mac OS (using property lists) as well as its dconf backend and is the proper API to use for graphical applications. so like, use that one. she's the moment 💜

👀 SEE ALSO 👀

📝 NOTES 📝

  1. GSettings — http://developer.gnome.org/gio/stable/GSettings.html

and that's the whole page, bestie!! 🎉 sign-off time: this was dconf, rendered as DCONF(7) at the bottom of the page — the source name dconf on the left, DCONF(7) on the right, iykyk 🫶 go forth and read your keys with zero system calls, mwah 💋

📦 where this page comes from