[systemd-devel] Vendor default masked service

[Umut Tezduyar Lindskog]

On Thu, May 28, 2015 at 6:25 PM, Lennart Poettering
<lennart at poettering.net> wrote:
> 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 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