[systemd-devel] Vendor default masked service

Dimitri John Ledkov dimitri.j.ledkov at intel.com
Thu May 28 05:15:48 PDT 2015

On 28 May 2015 at 12: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.

it will attempt to dbus activate non-existing service file.... since
there wouldn't be a symlink with a name
dbus-com.axis.foobar.waldi.service pointing to anything real, and thus
effectively masked, no?!


Pura Vida!

Open Source Technology Center
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ.

More information about the systemd-devel mailing list