Let D-Bus Start dconf-service When Settings Need Writing

You will finish with a safe way to understand and check dconf-service without trying to run it as an ordinary command. On this machine the guide uses dconf-service package version 0.40.0-4ubuntu0.1. 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.

Allow about ten minutes. You need a shell and, for the optional bus checks, a working user D-Bus session. The checks below are read-only. They do not edit a dconf key, restart a desktop component or change a service definition. No elevated privileges are normally required.

1. Confirm which package and service are installed

Start by checking the package version and the service definition. These 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. The executable is /usr/libexec/dconf-service, not a shell wrapper intended for interactive use.

Checkpoint: if the package query fails, stop here and install or repair the package through your normal distribution process. Do not work around a missing activation file by inventing a replacement unit.

2. Keep reads separate from writes

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

This distinction explains a common distraction. Looking for a long-running dconf-service process is not a useful test of whether dconf can be read. The service is stateless and can exit when it has no work. A process that is absent can be normal; a process that appears after a write can also be normal.

Do not start the executable directly:

$ /usr/libexec/dconf-service

That bypasses the activation contract and can leave you debugging the wrong thing. The manpage says users and administrators should not need to start the service. D-Bus owns that decision.

3. Inspect the user service without changing it

The package also installs a user systemd unit. Ask systemd to show the unit text rather than starting, stopping or restarting it:

$ 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. This is why a manual background process is the wrong repair for an activation problem. If the unit is not available in your session, that does not by itself prove that dconf is broken: the service can also be activated through the D-Bus service file shown in step 1.

Checkpoint: the command must print the unit contents without a pager prompt. If it reports that the user manager is unavailable, continue with package-file checks and diagnose the missing user session separately.

4. Check whether the bus currently knows the service

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. Treat both cases as compatible with normal operation.

If there is no user bus, busctl reports an error such as a failure to connect to the bus. That is a session-environment problem, not evidence that the dconf database is corrupt. Check the command from the same desktop login or service environment in which the application is running. Do not add sudo: root's bus is not a substitute for the user's session bus.

5. Test a real write through the application that owns it

Use the application or deployment tool that is meant to change the setting. Do not create a test key merely 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 through 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 no result by the time you run it. The useful observation is whether the application completed its write and whether the bus reported an activation error while it was doing so. The service may have started and exited between the two checks.

There is no service-level undo for this step because the configuration change belongs to the application and the dconf database. Undo it through the same application, or restore the recorded previous value using the supported configuration tool for that setting.

6. Diagnose a failed write without restarting the service

Separate the failure into three questions: can the application reach its session or system bus, can D-Bus activate ca.desrt.dconf, and does the application have permission to write the requested setting? The package file and unit checks above answer the second question only partially.

For a user service, inspect 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 absent log is not automatically a fault, because a successful activation may be brief and a failed application may never have reached dconf. If the application reports a D-Bus connection error, investigate the session environment first. If activation reports an executable or permission error, compare the installed path and package ownership with step 1.

Do not delete dconf databases, remove service files or restart the desktop bus as a first response. Those actions can disrupt other applications and can discard or obscure useful evidence. Repair the package or session configuration only after the error identifies the faulty layer, and keep a rollback plan for any persistent configuration change.