On Mon, 01.06.15 08:25, Umut Tezduyar Lindskog (u...@tezduyar.com) wrote:

> >> > Wouldn't that work?
> >>
> >> For dbus activation it would work but other services can still
> >> activate the service through systemd.
> >
> > But why is that a problem? If daemons explicitly request another
> > service by invoking StartUnit() via the bus, why block this off in
> > your usecase?
> I think you are right. As long as we can stop the service from being
> bus/socket activated (which we can), we should be good. Really not
> much to do for explicit requests.
> Our software has to interpret activation failure messages coming from
> dbus [1] somehow to "service shouldn't be started". I am guessing we
> should also be future compatible that these messages will come from
> someone else with kdbus or?
> [1] - sender=org.freedesktop.DBus destination=:1.57 object=n/a
> interface=n/a member=n/a cookie=3 reply_cookie=2 error=Unit
> dbus-com.axis.PrioritizedTextOverlay.service failed to load: No such
> file or directory.

Well, with kdbus in the mix the behaviour actually changes quite a
bit. If a .busname unit is active, then sending something to its name
will cause activation of the service for it. However, .busname units
can be started/stopped individually, and thus the busnames don't have
to be activatable all the time. This is quite different from dbus1
where there's only a single list of activatable names, that is in
effect right from the moment dbus-daemon is started to the very end.

Or in other words: if a bus service shall not be activatable using
kdbus/systemd, then you will get a "no such service" error back,
instead of a "failed to actviate" error...


Lennart Poettering, Red Hat
systemd-devel mailing list

Reply via email to