How to manually trigger a bus-activated service?

[Simon McVittie]

On Mon, 10 Feb 2025 at 19:38:24 -0800, Ross Boylan wrote:
> In brief, if I have a dbus .service file with Name=a.b.c, what
> arguments to the dbus-send command do I need to activate it?

To answer the question you asked: you can either send a message to the
service, which will start it as a side-effect ("autostarting"), or send
a message to the message bus itself and explicitly ask for the service
to be started:

dbus-send --system --print-reply \
    --dest=org.freedesktop.DBus \
    /org/freedesktop/DBus \
    org.freedesktop.DBus.StartServiceByName \
    string:a.b.c uint32:0

But I don't think the question you asked actually solves the problem
that you're trying to solve.

> # File /etc/dbus-1/system-services/boylan.ross.offsite-backup.service
> # system.conf modified to have
> <servicedir>/etc/dbus-1/system-services</servicedir>
> [D-BUS Service]
> Name=boylan.ross.offsite-backup
> Exec=/bin/false
> User=root
> SystemdService=boylan.ross.offsite-backup.service
> 
> # /etc/systemd/system/boylan.ross.offsite-backup.service
> [Unit]
> Description=Copy Backup and Important Files to Remote System
> 
> [Service]
> Type=dbus
> BusName=boylan.ross.offsite-backup-service
> ExecStart=/usr/bin/python3 /usr/local/sbin/bacula.py --wait --test
> --log file,syslog,email

I think you're making this too complicated for yourself. If you want
to run a backup program as a systemd service, forget about D-Bus; just
run the backup program as a systemd service.

You can tell systemd to start a particular service by sending it D-Bus
messages, if you want, but that doesn't require the service to be a D-Bus
service itself: it works because **systemd** is a D-Bus service.

(Analogous: you can equally well tell systemd to start a HTTP server
like Apache by sending it D-Bus messages, without requiring D-Bus to be
HTTP or requiring HTTP to be D-Bus.)

It seems like you have turned this into a D-Bus question when you perhaps
should instead have been asking a systemd question.

I think what you want here is probably a "one shot" systemd service that
runs bacula, and then use systemd's D-Bus API whenever you want to ask
for it to be started. (Or you could have a systemd timer that starts
the service, or both.)

> BusName=boylan.ross.offsite-backup-service
> ExecStart=/usr/bin/python3 /usr/local/sbin/bacula.py ...

This isn't going to work, unless you have modified /usr/local/sbin/bacula.py
so that it will request D-Bus name "boylan.ross.offsite-backup-service"
when it's ready to receive requests over D-Bus. (I suspect you have not,
and I suspect bacula doesn't receive requests over D-Bus.)

If bacula doesn't receive requests over D-Bus at all (as I suspect it does
not), then it isn't a D-Bus service, so it isn't appropriate to give it
a D-Bus .service file.

> [Service] Type=dbus, BusName=boylan.ross.offsite-backup-service
> [D-BUS Service] Name=boylan.ross.offsite-backup

I can't think of a situation where it would make sense for these two
names to be different.

> Sources on the net recommend Exec=/bin/false for the d-bus service,
> though the systemd.service man page example has the name of the
> service executable there and in the systemd service file.  Since I
> don't want to be trying to start it twice, I went with /bin/false.

The Exec line in the D-Bus service file is only used if systemd activation
is not possible. The service won't be run twice: it will either be started
by asking systemd to start it, or directly by the message bus by running
its Exec command, but not both.

> If ExecStart ever works, my intention is that the program (bacula.py)
> will run and exit.  A new activation will cause a new launch.  But
> what I've read suggests the program exec'd is supposed to stick around
> and catch later signals.  How to approach that?

Most likely you would need to be an author of bacula, and change the
design of bacula. If you don't want to do that, then writing a D-Bus
service file is the wrong tool to solve whatever problem you are aiming
to solve.

> I'm unsure if there is a safe way to force a reload of the
> configuration of the system bus for d-bus.

(There is, see elsewhere in this thread)

    smcv