On Thu, 28.05.15 13:56, Umut Tezduyar Lindskog (u...@tezduyar.com) wrote: > On Thu, May 28, 2015 at 1:17 PM, Lennart Poettering > <lenn...@poettering.net> wrote: > > On Wed, 27.05.15 13:05, Umut Tezduyar Lindskog (u...@tezduyar.com) wrote: > > > >> On Tue, May 26, 2015 at 4:14 PM, Lennart Poettering > >> <lenn...@poettering.net> wrote: > >> > On Tue, 26.05.15 11:53, Umut Tezduyar Lindskog (u...@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 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 _______________________________________________ systemd-devel mailing list email@example.com http://lists.freedesktop.org/mailman/listinfo/systemd-devel