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? Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
