On Thu, May 28, 2015 at 6:25 PM, Lennart Poettering <lenn...@poettering.net> wrote: > On Thu, 28.05.15 13:56, Umut Tezduyar Lindskog (u...@tezduyar.com) wrote: > >> On Thu, May 28, 2015 at 1:17 PM, Lennart Poettering >> <lenn...@poettering.net> wrote: >> > On Wed, 27.05.15 13:05, Umut Tezduyar Lindskog (u...@tezduyar.com) wrote: >> > >> >> On Tue, May 26, 2015 at 4:14 PM, Lennart Poettering >> >> <lenn...@poettering.net> wrote: >> >> > On Tue, 26.05.15 11:53, Umut Tezduyar Lindskog (u...@tezduyar.com) >> >> > wrote: >> >> > >> >> >> Hi, >> >> >> >> >> >> I was wondering if we have a way to provide vendor default masked >> >> >> service? >> >> > >> >> > Well, so far our thinking was that if the vendor wants to make a unit >> >> > completely unavailable he should simply not ship it in the first >> >> > place. >> >> > >> >> > What's the usecase for a vendor masking a unit, but installing it? Why >> >> > not remove it in the first place entirely? >> >> >> >> If we ship a product without the service, we don't have a way of >> >> installing it again once the product is deployed. >> >> >> >> Use case would be: We use one software for a video encoder blade with >> >> multiple CPUs. Every CPU runs the same software. We have a special >> >> service which should only run on the first CPU. A generator installs >> >> the .wants link for the service on first CPU. Another service could >> >> try to talk to the special service over dbus causing it to be dbus >> >> activated (where special service is only allowed to be up on first >> >> CPU). We could install the dbus activation files with generator but it >> >> gets messy to offload this logic to a generator. Also, special service >> >> can be activated by using systemd's dbus interface. >> > >> > My recommendation would be to ship the dbus service file always, but >> > make it direct to SystemdService=dbus-com.axis.foobar.waldi.service, >> > and then manage dbus-com.axis.foobar.waldi.service as a symlink alias >> > to the real bus service. All you do in your generator now is create >> > the symlink or not create it... >> > >> > 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. Umut > > I can understand you don't want implicit activation via socket, boot, > bus but that's all easily managable via "systemctl disable" and > "systemctl enable". What am I missing? > > Lennart > > -- > Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
