On Sat, Sep 17, 2022 at 6:45 PM Lennart Poettering <lenn...@poettering.net> wrote:
> 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? > 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
