dbus-daemon-launch-helper — launch system services on demand from the Desktop Bus broker


dbus-daemon-launch-helper {service-name}


dbus-daemon-launch-helper is called by the Desktop Bus broker daemon whenever it wants to launch a D-BUS service that isn't yet running "on demand" in response to clients attempting to communicate with that service over the Desktop Bus.

It supersedes an old command of the same name that is supplied with the D-BUS broker. The D-BUS broker daemon has to be instructed to invoke it via a configuration change in /etc/dbus-1/system.conf and /etc/dbus-1/session.conf. (Drop-in configuration snippets do not work for this, alas.) It isn't really useful to run it directly.

The {service-name} argument is the name of a service as it is known to the D-BUS broker, i.e. the name of its service file under /usr/share/dbus-1/system-services/ or /usr/share/dbus-1/services/. dbus-daemon-launch-helper simply attempts to start a service by that name, stripping any trailing .service or any leading dbus-.

It attempts to auto-detect which command of system-control(1) reset, initctl(1) start, or systemctl(1) start to use to start the service. Unlike the command that it supersedes, it attempts to respect the enable/disable configuration of the service, and to not demand-start disabled services.

If a D-BUS service daemon is running but currently disabled, it will respect the enable/disable state to the extent of stopping that service. However, this scenario does not occur in practice. If a D-BUS service daemon is running, the D-BUS broker daemon does not need to, and thus attempt to, start it on demand in the first place.


This program has, unlike its predecessors, no reason to be set-UID or set-GID. It does not attempt to run daemons directly itself.

It runs under the aegis of the same unprivileged user account that the D-BUS broker daemon itself runs under. Whatever service management system is in place must therefore be configured so that (only) the requisite services can be started by that account invoking the relevant service management command. With the nosh toolset's system-control(1), for example, this means granting the necessary privileges to the control FIFOs in the various service bundles' supervise/ directories.

Avoiding Desktop Bus activation

Properly, this command should go through an extensive dance:

  1. Search /usr/share/dbus-1/system-services/ or /usr/share/dbus-1/services/ for a (D-BUS) service definition file named {service-name}.

  2. Parse that file as a Microsoft INI file looking for the [D-BUS Service] section.

  3. If it has an SystemdService= setting, attempt to start the service named there.

  4. Otherwise, if it has an Exec= setting, run the command named there as the superuser.


  • Executing any D-BUS server daemon directly from the D-BUS broker daemon is a bad idea. All D-BUS server programs should only be executed via, and under the control of, service management. Respecting Exec= is wholly the wrong thing to do.

  • The SystemdService= setting is just the inverse of a mechanism that provides alias names for service managed services. If every service managed service has an alias that is its D-BUS service (file) name, then one can completely ignore SystemdService= and just use the D-BUS {service-name} as it stands.

By adopting the principles that all D-BUS server daemons must be managed by service management and that all such services must have an alias that matches their D-BUS service (file) names, dbus-daemon-launch-helper can thus ignore the contents of the D-BUS service file entirely. Indeed, it does not even need to locate and open the D-BUS service file. It solely relies upon the D-BUS service (file) name mapping to the service management service name, either directly or via an alias that has been set up in service management configuration.


Jonathan de Boyne Pollard