dconf - A configuration system
dconf is a simple key/value storage system that is heavily optimised for
reading. This makes it an ideal system for storing user preferences (which are
read 1000s of times for each time the user changes one). It was created with
this usecase in mind.
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. The binary file for the defaults can optionally
be compiled from a set of plain text keyfiles.
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 modifies a preference). The service is stateless and can exit freely at
any time (and is therefore robust against crashes). The list of paths that
each process is watching is stored within the D-Bus daemon itself (as D-Bus
signal match rules).
Reads are performed by direct access (via mmap) to the on-disk database which is
essentially a hashtable. For this reason, 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.
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. On some file systems, dconf-service will call fsync() for
every write, which can introduce a latency of up to 100ms. 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 binary database format that dconf uses by default is not suitable for use on
NFS, where mmap does not work well. To handle this common use case, dconf can
be configured to place its binary database in XDG_RUNTIME_DIR
guaranteed to be local, but non-persistent) and synchronize it with a plain
text keyfile in the users home directory.
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
On startup, dconf consults the DCONF_PROFILE
environment variable. If
set, dconf will attempt to open the named profile, aborting if that fails. 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.
can specify a relative path to a file in
/usr/local/etc/dconf/profile/, or an absolute path (such as in a user's home
directory). The profile name can only use alphanumeric characters or '_'.
A profile file might look like the following:
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.)
A "user-db" line specifies a user database. These databases are found
/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. 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).
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
/dconf/user.txt. The synchronization is bi-directional.
A "system-db" line specifies a system database. These databases are
found in /usr/local/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:
That is, the user's personal database is consulted and there are no system
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 /usr/local/etc/dconf/db/ database
The keyfiles contain groups of settings as follows:
# Some useful default settings for our site
After changing keyfiles, the database needs to be updated with the
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.
To add locks to a database, place text files in the /usr/local/etc/dconf/db/
.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
After changing locks, the database needs to be updated with the dconf
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). 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).
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. The wrapper API used by GTK+ and GNOME
applications is GSettings
, 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