[systemd-devel] Vendor default masked service

[Umut Tezduyar Lindskog]

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.

Umut

>
> Lennart
>
> --
> Lennart Poettering, Red Hat