[systemd-devel] Vendor default masked service
Umut Tezduyar Lindskog
umut at tezduyar.com
Sun May 31 23:25:35 PDT 2015
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  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?
 - 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.
> 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 Poettering, Red Hat
More information about the systemd-devel