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?


Lennart Poettering, Red Hat
systemd-devel mailing list

Reply via email to