Re: [systemd-devel] Can /usr/lib/systemd/user/sockets.target.wants be used to autoenable a socket by a vendor package?
After experimenting some more, I can see that if there's no [Install] section and the unit is enabled by putting it into /usr/lib/systemd/*/*.target.wants, then is-enabled is static, and `systemctl enable` does nothing and explains the situation. Which makes me think that one should either add the [Install] section, or enable a unit via /usr/lib/systemd/*/*.target.wants. If both are done, is-enabled is disabled, and one can enable it twice (provide a second route). Which probably is not particularly bad, but is confusing. On Tue, Sep 20, 2022 at 11:23 AM Andrei Borzenkov wrote: > > On Tue, Sep 20, 2022 at 10:42 AM Barry wrote: > > > > Enabled does mean that it will or will not run. > > It means that it is wanted by the default target. > > > > No. It means that it is wanted by whatever units are listed in > [Install] section (actually, it is "enabled" even if only aliases are > created, so more correct is - it is enabled if links mentioned in > [Install] section are created).
Re: [systemd-devel] Can /usr/lib/systemd/user/sockets.target.wants be used to autoenable a socket by a vendor package?
On Tue, Sep 20, 2022 at 10:42 AM Barry wrote: > > Enabled does mean that it will or will not run. > It means that it is wanted by the default target. > No. It means that it is wanted by whatever units are listed in [Install] section (actually, it is "enabled" even if only aliases are created, so more correct is - it is enabled if links mentioned in [Install] section are created).
Re: [systemd-devel] Can /usr/lib/systemd/user/sockets.target.wants be used to autoenable a socket by a vendor package?
> On 18 Sep 2022, at 13:08, Yuri Kanivetsky wrote: > > >> >>> $ ls -al >>> /usr/lib/systemd/user/multi-user.target.wants/infinite-tsukuyomi.service >>> lrwxrwxrwx 1 root root 29 Sep 18 08:45 >>> /usr/lib/systemd/user/multi-user.target.wants/infinite-tsukuyomi.service >>> -> ../infinite-tsukuyomi.service >>> >>> And rebooted the machine. The service didn't start. But starts >>> manually if I tell it to. Is there anything I'm missing here? >>> >> >> There is no multi-user.target for user systemd instances (nothing >> prevents you from creating one, but it does not exist by default). > > Good point. When I symlink it into > /usr/lib/systemd/user/default.target.wants it starts on boot. > > Also, I've created a simple perl server: > > https://gist.github.com/x-yuri/45f53c16a99337ba0716a988290491bd > > And if I put perl-server.socket and perl-server.service into > /usr/lib/systemd/user, and symlink perl-server.socket into > /usr/lib/systemd/user/sockets.target.wants, it autoactivates on boot. > > The confusing thing though is: > > $ systemctl --user is-enabled perl-server.socket > disabled Enabled does mean that it will or will not run. It means that it is wanted by the default target. Barry > > And the fact that enable/preset/disable create/remove symlinks in > ~/.config/systemd/user/sockets.target.wants. > > Which doesn't happen with a service (e.g. infinite-tsukuyomi) when the > service is in /usr/lib/systemd/user. > > Regards, > Yuri >
Re: [systemd-devel] Can /usr/lib/systemd/user/sockets.target.wants be used to autoenable a socket by a vendor package?
Yuri Kanivetsky wrote on 18/09/2022 13:08: Also, I've created a simple perl server: https://gist.github.com/x-yuri/45f53c16a99337ba0716a988290491bd And if I put perl-server.socket and perl-server.service into /usr/lib/systemd/user, and symlink perl-server.socket into /usr/lib/systemd/user/sockets.target.wants, it autoactivates on boot. The confusing thing though is: $ systemctl --user is-enabled perl-server.socket disabled Unless your per-server.socket unit has an [Install] section that corresponds to the manual symlinks you've made, the is-enabled test will fail. Ultimately the [Install] section is just instructions to "systemctl [--user] enable|disable" to create/delete these symlinks for you as needed. These same hints are used by is-enabled to check whether it is enabled. If you don't have the correct [Install] section, it won't know by which route it ultimately becomes enabled if you do the links manually. Hope that helps explain things. Col -- Colin Guthrie
Re: [systemd-devel] Can /usr/lib/systemd/user/sockets.target.wants be used to autoenable a socket by a vendor package?
> > $ ls -al > > /usr/lib/systemd/user/multi-user.target.wants/infinite-tsukuyomi.service > > lrwxrwxrwx 1 root root 29 Sep 18 08:45 > > /usr/lib/systemd/user/multi-user.target.wants/infinite-tsukuyomi.service > > -> ../infinite-tsukuyomi.service > > > > And rebooted the machine. The service didn't start. But starts > > manually if I tell it to. Is there anything I'm missing here? > > > > There is no multi-user.target for user systemd instances (nothing > prevents you from creating one, but it does not exist by default). Good point. When I symlink it into /usr/lib/systemd/user/default.target.wants it starts on boot. Also, I've created a simple perl server: https://gist.github.com/x-yuri/45f53c16a99337ba0716a988290491bd And if I put perl-server.socket and perl-server.service into /usr/lib/systemd/user, and symlink perl-server.socket into /usr/lib/systemd/user/sockets.target.wants, it autoactivates on boot. The confusing thing though is: $ systemctl --user is-enabled perl-server.socket disabled And the fact that enable/preset/disable create/remove symlinks in ~/.config/systemd/user/sockets.target.wants. Which doesn't happen with a service (e.g. infinite-tsukuyomi) when the service is in /usr/lib/systemd/user. Regards, Yuri
Re: [systemd-devel] Can /usr/lib/systemd/user/sockets.target.wants be used to autoenable a socket by a vendor package?
On 18.09.2022 09:05, Yuri Kanivetsky wrote: >> No, everything linked to a .wants/ directory immediately becomes a >> Wants= dep of and is therefore "enabled", it doesn't matter whether >> that .wants/ is in /etc or /usr/lib or /run. > > To confirm this, I created the following files: > > $ cat /usr/lib/systemd/user/infinite-tsukuyomi.service > [Unit] > Description=Infinite Tsukuyomi > > [Service] > ExecStart=/usr/bin/sleep infinity > > $ ls -al > /usr/lib/systemd/user/multi-user.target.wants/infinite-tsukuyomi.service > lrwxrwxrwx 1 root root 29 Sep 18 08:45 > /usr/lib/systemd/user/multi-user.target.wants/infinite-tsukuyomi.service > -> ../infinite-tsukuyomi.service > > And rebooted the machine. The service didn't start. But starts > manually if I tell it to. Is there anything I'm missing here? > There is no multi-user.target for user systemd instances (nothing prevents you from creating one, but it does not exist by default).
Re: [systemd-devel] Can /usr/lib/systemd/user/sockets.target.wants be used to autoenable a socket by a vendor package?
> No, everything linked to a .wants/ directory immediately becomes a > Wants= dep of and is therefore "enabled", it doesn't matter whether > that .wants/ is in /etc or /usr/lib or /run. To confirm this, I created the following files: $ cat /usr/lib/systemd/user/infinite-tsukuyomi.service [Unit] Description=Infinite Tsukuyomi [Service] ExecStart=/usr/bin/sleep infinity $ ls -al /usr/lib/systemd/user/multi-user.target.wants/infinite-tsukuyomi.service lrwxrwxrwx 1 root root 29 Sep 18 08:45 /usr/lib/systemd/user/multi-user.target.wants/infinite-tsukuyomi.service -> ../infinite-tsukuyomi.service And rebooted the machine. The service didn't start. But starts manually if I tell it to. Is there anything I'm missing here? Regards, Yuri
Re: [systemd-devel] Can /usr/lib/systemd/user/sockets.target.wants be used to autoenable a socket by a vendor package?
On Sat, Sep 17, 2022 at 8:35 PM Yuri Kanivetsky
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/e7a6851881e2cfea37b76cfb16ba97af2fcc
>
> 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 .wants/ directory immediately becomes a
Wants= dep of 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 `. 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
