[systemd-devel] Can /usr/lib/systemd/user/sockets.target.wants be used to autoenable a socket by a vendor package?

[Mantas Mikulėnas]

On Sat, Sep 17, 2022 at 8:35 PM Yuri Kanivetsky <yuri.kanivetsky at gmail.com>
wrote:

> Hi,
>
> I've noticed that an Arch Linux package (gnupg) seemingly
> automatically enables a socket:
>
> ln -s "../dirmngr.socket"
> "/usr/lib/systemd/user/sockets.target.wants/dirmngr.socket"
>
>
> https://github.com/archlinux/svntogit-packages/commit/e74444a6851881e2cfea37b76cfb16ba97af2fcc
>
> Before the change they were symlinked to
> /etc/systemd/user/sockets.target.wants.
>
> Later I was told that there's such a thing as preset units (an
> undocumented feature?):
>
> https://bbs.archlinux.org/viewtopic.php?pid=2057758#p2057758
>
> The way I understood it, if I put dirmngr.socket at
> /usr/lib/systemd/user/sockets.target.wants, it's like adding "enable
> dirmngr.service" to the preset policy. In other words, it won't be
> enabled by default, and won't be activated on boot unless I do
> `systemctl --user preset dirmngr`.
>

No, everything linked to a <unit>.wants/ directory immediately becomes a
Wants= dep of <unit> and is therefore "enabled", it doesn't matter whether
that .wants/ is in /etc or /usr/lib or /run.

In fact, units linked into /usr/.../*.wants/ are enabled *permanently, *as
the sysadmin can no longer `systemctl` disable them at all – they can only
be masked. So the Arch change is moving into the opposite direction than
what you thought.


> Can you clarify this? Are there preset units? Is my understanding of
> how they work correct?
>

It's not entirely correct. Systemd indeed has presets, but they work
differently – there are separate config files in
/usr/lib/systemd/{user,system}-preset/ that would be read by a `systemctl
preset <unit>`. See systemd.preset(5) for details. (For example,
https://aur.archlinux.org/cgit/aur.git/tree/?h=softu2f uses presets to
enable sockets by default.)

So the reason systemctl says "preset: enabled" is *not *because of any
existing .wants/ symlinks (those still correspond to the main "enabled"
status) – instead it's because the unit doesn't match any .preset files
that would disable it (i.e. it only matches the compiled-in default "enable
*" preset), and therefore systemctl *would create *a .wants/ symlink from
the preset.

-- 
Mantas Mikulėnas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20220917/d850a59a/attachment.htm>