[systemd-devel] Vendor default masked service

Lennart Poettering lennart at poettering.net
Thu May 28 04:17:04 PDT 2015

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?


Lennart Poettering, Red Hat

More information about the systemd-devel mailing list