Understand dconf-service Without Running It by Hand

You went looking for dconf-service in the process list and it was not there, so you assume dconf is broken. It probably is not: D-Bus starts this service only when something needs to write a setting. This guide uses package version 0.40.0-4ubuntu0.1, takes about ten minutes, and shows you how to check the service safely.

The service provides the ca.desrt.dconf name on a D-Bus session or system bus, and D-Bus starts it when an application needs to write to the dconf database.

• You need: a shell and, for the optional bus checks, a working user D-Bus session.
• What it touches: nothing. Every check is read-only. No dconf key is edited, no desktop component restarted and no service definition changed.
• Privileges: none normally required.

1. Confirm the package and service file

Check the package version and the service definition. Both are ordinary inspection commands:

$ dpkg-query -W -f='${Package} ${Version}\n' dconf-service
dconf-service 0.40.0-4ubuntu0.1
$ sed -n '1,80p' /usr/share/dbus-1/services/ca.desrt.dconf.service
[D-BUS Service]
Name=ca.desrt.dconf
Exec=/usr/libexec/dconf-service
SystemdService=dconf.service

The file maps the well-known D-Bus name to the installed executable. That executable is /usr/libexec/dconf-service, not a shell wrapper meant for interactive use.

2. Keep reads separate from writes

This service is not the general dconf command line interface. The installed manpage draws a narrow line: reading values from dconf does not involve this service, while writes do. An application using GSettings or another dconf client may only cause the service to appear when it changes a setting.

That is why hunting for a long-running dconf-service process tells you nothing about whether dconf can be read. The service is stateless and can exit when it has no work. Absent can be normal. Present after a write can also be normal.

Do not start the executable directly:

$ /usr/libexec/dconf-service

3. Read the user unit

The package also installs a user systemd unit. Ask systemd to print the unit text rather than start, stop or restart anything:

$ systemctl --user cat dconf.service
[Unit]
Description=User preferences database
Documentation=man:dconf-service(1)

[Service]
ExecStart=/usr/libexec/dconf-service
Type=dbus
BusName=ca.desrt.dconf

Type=dbus and BusName=ca.desrt.dconf describe a service that becomes ready by acquiring its bus name. So a manual background process is the wrong repair for an activation problem.

If the unit is not available in your session, that does not prove dconf is broken. The service can also be activated through the D-Bus service file from step 1.

4. Ask the bus whether it knows the name

If your shell has a user D-Bus session, inspect the name without requesting a write:

$ busctl --user status ca.desrt.dconf
NAME                 PID PROCESS
ca.desrt.dconf       ... dconf-service

The PID and process details vary. A successful result means the name is currently owned. The name may be absent before a write, or after the stateless service has exited. Both are compatible with normal operation.

With no user bus, busctl reports an error such as a failure to connect to the bus. That is a session-environment problem, not evidence of a corrupt dconf database. Run the check from the same desktop login or service environment as the application.

5. Trigger a real write through its owner

Use the application or deployment tool that is meant to change the setting. Do not create a test key just to make the service start, and do not edit dconf's database files directly. A write is configuration state, so confirm the exact key and record its previous value before changing anything.

For a desktop setting, make one deliberate change in the desktop's own settings application, then inspect the bus and the process list:

$ busctl --user status ca.desrt.dconf
$ pgrep -a -x dconf-service

Either command may show nothing by the time you run it, because the service may have started and exited between the two checks. What matters is whether the application completed its write and whether the bus reported an activation error along the way.

6. Diagnose a failed write without restarting anything

Split the failure into three questions:

• Bus reach. Can the application reach its session or system bus?
• Activation. Can D-Bus activate ca.desrt.dconf?
• Permission. Does the application have permission to write the requested setting?

The package file and unit checks above only partly answer the second question. For a user service, read recent user-manager messages without changing state:

$ journalctl --user -u dconf.service --since '15 minutes ago' --no-pager

Read the timestamps and the first concrete error. An empty log is not automatically a fault: a successful activation may be brief, and a failed application may never have reached dconf.

• D-Bus connection error: investigate the session environment first.
• Executable or permission error on activation: compare the installed path and package ownership with step 1.