dbus-daemon-launch-helper 1 user commands nosh 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 dæmon 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 dæmon 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 service name requested by some D-BUS client. dbus-daemon-launch-helper simply attempts to start a service management service by that same name, stripping any trailing .service or any leading dbus-. It attempts to auto-detect which command of system-control1 reset, initctl1 start, or systemctl1 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 dæmon 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 dæmon is running, the D-BUS broker dæmon 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 dæmons directly itself. It runs under the aegis of the same unprivileged user account that the D-BUS broker dæmon 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-control1, for example, this means granting the necessary privileges to the control FIFOs in the various service bundles' supervise/ directories. Properly, this command should go through an extensive dance: Search /usr/{local/,}share/dbus-1/system-services/ or /usr/{local/,}share/dbus-1/services/ for a (D-BUS) service definition file (not necessarily named service-name.service, note). Parse that file as a Microsoft INI file looking for the [D-BUS Service] section that has a Name= setting matching service-name. If it has an SystemdService= setting, attempt to start the service named there. Otherwise, if it has an Exec= setting, run the command named there as the superuser. However: Executing any D-BUS server dæmon directly from the D-BUS broker dæmon 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 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 dæmons must be managed by service management and that all such services must have an alias that matches their D-BUS service names, dbus-daemon-launch-helper can thus ignore the contents of the D-BUS service files entirely. Indeed, it does not even need to locate and open the D-BUS service file. It solely relies upon the D-BUS service 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