[systemd-devel] Vendor default masked service

[Lennart Poettering]

On Thu, 28.05.15 13:56, Umut Tezduyar Lindskog (umut at tezduyar.com) wrote:

> On Thu, May 28, 2015 at 1:17 PM, Lennart Poettering
> <lennart at poettering.net> wrote:
> > On Wed, 27.05.15 13:05, Umut Tezduyar Lindskog (umut at tezduyar.com) wrote:
> >
> >> On Tue, May 26, 2015 at 4:14 PM, Lennart Poettering
> >> <lennart at poettering.net> wrote:
> >> > On Tue, 26.05.15 11:53, Umut Tezduyar Lindskog (umut at 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 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