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 -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
