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
[systemd-devel] Can /usr/lib/systemd/user/sockets.target.wants be used to autoenable a socket by a vendor package?
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`. Can you clarify this? Are there preset units? Is my understanding of how they work correct? Regards, Yuri
Re: [systemd-devel] boot-complete.target dependencies issue
On 17.09.2022 19:44, Lennart Poettering wrote: > > So, my recommended fix: add After=multi-user.target to your > service. Note that systemd handling of .wants/ works like this: > > 1. add Wants= type dep > 2. if no After=/Before= dep is set, then also add Before= > That's not what manual page says. Is it documented anywhere? Manual page says that .wants/ it equivalent of Wants and that "Target units will automatically complement all configured dependencies of type Wants= or Requires= with dependencies of type After= unless DefaultDependencies=no is set in the specified units". Nowhere does it say "unless other ordering dependencies already exist".
Re: [systemd-devel] boot-complete.target dependencies issue
On Fr, 16.09.22 10:10, Antonio Murdaca (run...@redhat.com) wrote: > Hi, following > https://systemd.io/AUTOMATIC_BOOT_ASSESSMENT/#how-to-adapt-this-scheme-to-other-setups > I've been experimenting on a fedora system > with systemd-boot-check-no-failures.service and the ability to have > services run "after" boot-complete.target. The basic use case would just to > have something that checks services are up and running, reach boot-complete > if they are, and start other services afterwards. > I've taken from that blog this piece specifically: > ``` > To support additional components that shall only run on boot success, > simply wrap them in a unit and order them after boot-complete.target, > pulling it in. > ``` > So I've done the following with an example service and by enabling : > > # cat /etc/systemd/system/test.service > [Unit] > Description="Order after boot-complete.target, pulling it in" > After=boot-complete.target > Requires=boot-complete.target > > [Service] > Type=oneshot > ExecStart=/usr/bin/echo "Additional component that shall only run on boot > success" > RemainAfterExit=yes > > [Install] > WantedBy=default.target > > # systemctl enable test.service systemd-boot-check-no-failures.service > Created symlink /etc/systemd/system/default.target.wants/test.service → > /etc/systemd/system/test.service. > Created symlink > /etc/systemd/system/boot-complete.target.requires/systemd-boot-check-no-failures.service > → /usr/lib/systemd/system/systemd-boot-check-no-failures.service. > > # systemctl reboot > > Unfortunately, the above results in: > > systemd[1]: multi-user.target: Found ordering cycle on test.service/start > systemd[1]: multi-user.target: Found dependency on > boot-complete.target/start > systemd[1]: multi-user.target: Found dependency on > systemd-boot-check-no-failures.service/start > systemd[1]: multi-user.target: Found dependency on multi-user.target/start > systemd[1]: multi-user.target: Job test.service/start deleted to break > ordering cycle starting with multi-user.target/start > > so what's the correct way to perform the mentioned "order [units] after > boot-complete.target", if they cannot be pulled in through the usual > default/multi-user targets? If I add DefaultDependencies=no to test.service > it now appears to work w/o the dependency cycle. It should suffice adding After=multi-user.target to your service. The things is that systemd-boot-check-no-failures.service runs late, after the startup transaction is done to check if everything succeeded. But now you want to run something more, so by default s-b-c-n-f.s would also want to run after that, to know if it succeeded. But htat of course makes little sense: the output of your service cannot be part of the input of s-b-c-n-f.s if your service should run after s-b-c-n-f.s! So, my recommended fix: add After=multi-user.target to your service. Note that systemd handling of .wants/ works like this: 1. add Wants= type dep 2. if no After=/Before= dep is set, then also add Before= This means, that just adding an explicit After=multi-user.target to your service means rule #2 won't take effect anymore. With that in place things should just work (untested, but afaics), as it means s-b-c-n-f.s can run after multi-user.target, and then boot-complete.target after that, and then finally your service. Does that make sense? Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] Real-time scheduling doesn't work with StartupCPUWeight/CPUWeight
On Mi, 14.09.22 15:03, Robert Tiemann (r...@gmx.de) wrote: > Hi! > > I have optimized boot times for an embedded system by setting > StartupCPUWeight= and CPUWeight= for a few services. The startup > values are set to various values. All unit files I have touched also > contain the line "CPUWeight=100" so that the system is running with > defaults after startup. Some unit files contain Nice= assignments > (placed there before my optimizations, so I kept them in place). > > Now, the problem is with one process in the system which requires > real-time priorities. It calls pthread_setschedparam() to configure > two of its threads for SCHED_RR policy at priority 99. This used to > work before my optimizations, but now pthread_setschedparam() fails > with EPERM error. I have added LimitRTPRIO=infinity, but it still > doesn't work. The threads are created and configured after the startup > phase has finished. Please consult README, look for comment on CONFIG_RT_GROUP_SCHED=n. Lennart -- Lennart Poettering, Berlin
