Re: boot-complete.target dependencies issue

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On Sat, Sep 17, 2022 at 6:45 PM Lennart Poettering <lennart@xxxxxxxxxxxxxx> wrote:
On Fr, 16.09.22 10:10, Antonio Murdaca (runcom@xxxxxxxxxx) 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?

that works and makes total sense! thanks! I'd enhance the documentation around that as it wasn't immediately clear to me that adding After would result in that though!
thanks!
 

Lennart

--
Lennart Poettering, Berlin



--
Antonio (runcom) Murdaca
Principal Software Engineer
B056 8311 87B3 DDEB 25B5 01AF CC5C 9A81 EDCA D821

[Index of Archives]     [LARTC]     [Bugtraq]     [Yosemite Forum]     [Photo]

  Powered by Linux