Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages


home | help
DCONF(7)		 Conventions and miscellaneous		      DCONF(7)

       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 (which is guaranteed to be local, but non-persistent)
       and synchronize it with a plain text keyfile in the users home

       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.

       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.  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

       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
       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. 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 $XDG_CONFIG_HOME/dconf/user.txt. The synchronization is

       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:


       That is,	the user's personal database is	consulted and there are	no
       system settings.

       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



       After changing keyfiles,	the database needs to be updated with the
       dconf(1)	tool.

       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
       /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

       After changing locks, the database needs	to be updated with the
       dconf(1)	tool.

       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[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.

       dconf-service(1), dconf-editor(1), dconf(1), GSettings[1]

	1. GSettings

dconf								      DCONF(7)


Want to link to this manual page? Use this URL:

home | help