[Whonix-devel] [Install] for static systemd unit file?

Patrick Schleizer patrick-mailinglists at whonix.org
Sat Mar 4 06:41:00 CET 2017

Michael Biebl:
> Am 01.03.2017 um 21:51 schrieb Patrick Schleizer:
>> Michael Biebl:
>>> Am 01.03.2017 um 21:35 schrieb Patrick Schleizer:
>>>> Hi!
>>>> TLDR:
>>>> How should the [Install] section for static systemd unit file look like?
>>> The obvious question is: why does this service need to be statically
>>> enabled?
>> Given the example... With this socket / service file combination, I
>> wouldn't know how to enable the service non-statically. In the current
>> implementation it looks to me right, and works.
> Just wanted to add that this was partially a misunderstanding on my
> part. When Patrick was talking about a static service, I was thinking
> about one which is enabled by shipping symlinks in the package in /lib/.
> I guess what Patrick wants is a service which simply has no [Install]
> section at all, because it's not activated by being pulled in via a
> target but via some other triggers.

This summary is totally right.

> This is perfectly fine, fwiw. Lintian is just overly ambitious here.
> Instead of inventing a WantedBy=none.target, it's better to just ignore
> or override that lintian warning.

Yes, doing that now.

> That all said, socket activation is not only about lazy loading, as you
> mentioned in a later email. It's more about avoid explicit dependencies.
> It's perfectly fine to have a socket-activated service which is also
> pulled in by a target like multi-user.target.

That's an important information. Learned something. :)

> Hope that clarifies. Sorry for the confusion this might have caused.

No problem. I appreciate your help here on this list and my daily Debian
anyhow. :)


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: OpenPGP digital signature
URL: <http://www.whonix.org/pipermail/whonix-devel/attachments/20170304/cb30df1c/attachment.sig>

More information about the Whonix-devel mailing list