How to manually trigger a bus-activated service?

[Simon McVittie]

On Tue, 11 Feb 2025 at 13:20:23 -0800, Ross Boylan wrote:
> The dbus spec is quite clear that names don't
> include `-`; I thought it was OK because other files were using it,
> and even the systemd.service man page's example of a dbus-activated
> service features a dbus service with `-` in the name (:

There is more than one kind of "name" in D-Bus.

Member names don't allow dashes.

Interface names don't allow dashes.

Bus names *do* allow dashes (but it's less confusing if you avoid them).

Reference for all three of those:
https://dbus.freedesktop.org/doc/dbus-specification.html#message-protocol-names

Object paths don't allow dashes, and use slashes instead of dots.

Reference:
https://dbus.freedesktop.org/doc/dbus-specification.html#message-protocol-marshaling-object-path

The assertion message you quoted mentions a "valid path", so it's
complaining that your object path contains a dash.

> Error org.freedesktop.DBus.Error.AccessDenied: Rejected send message
...
> The first part of the response looks like a permission problem

The system bus has a deny-by-default policy. Method calls aren't allowed
unless there's a policy rule in /usr/share/dbus-1/system.d/ or
/etc/dbus-1/system.d/ that says they are allowed.

Typical D-Bus system services like udisks2, upower, NetworkManager,
fwupd, systemd, ... install a policy rule that allows what they need
to allow.

Often the policy is to allow anyone to send method calls to the service,
and then the service uses polkit (formerly PolicyKit) to check whether
a higher-level, domain-specific action should be allowed or denied.
This is better than having the message bus apply fine-grained authorization
rules, because the message bus's language for writing authorization rules
is difficult to use and dangerous to get wrong.

> I'm not sure what the `error name="(unset)"` at the end is about; is
> it telling me  that it is an error that the name is not set?

No, nothing so advanced: it's telling you various details of the message
that wasn't allowed to be sent, and one of those details is the error
name. For any valid method call that will always be missing, represented
as "(unset)" in the log message, but other types of message might contain
an error name.

The logging is relatively simplistic and doesn't try to distinguish between
the fields that would be valid in different types of message: it just shows
you the values of all fields that might conceivably be relevant to an
authorization decision.

> The proof of "some awareness" of my modified files is indirect: if I
> send to  a different destination I get an error that the destination
> is not provided by any .service file.  So it knows the destination
> boylan.ross.remotebackup is provided by a .service file, even though I
> didn't do anything explicit to load it.

By default the dbus-daemon monitors existing directories that can contain
.service files using inotify, and reloads automatically when a change
occurs. Ideally you shouldn't rely on that, and instead you should call
the ReloadConfig method (or equivalently `systemctl reload dbus.service`)
when you want a change to take effect.

With hindsight, this use of inotify was probably a mistake, and it would
probably have been better to only reload when explicitly asked to reload
(like systemd does); but lots of people are probably relying on the
inotify, so we can't really remove it now.

`systemctl reload dbus.service` ends up calling something like this:

    dbus-send --print-reply --system --type=method_call --dest=org.freedesktop.DBus / org.freedesktop.DBus.ReloadConfig

which nicely illustrates how you could force a reload (you could think of
this as the D-Bus equivalent of `systemctl daemon-reload`).

    smcv