Re: [systemd-devel] boot-complete.target dependencies issue
On Sat, Sep 17, 2022 at 6:45 PM Lennart Poettering 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
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] boot-complete.target dependencies issue
On Fri, Sep 16, 2022 at 11:48 AM Antonio Murdaca wrote: > > > On Fri, Sep 16, 2022 at 11:38 AM Andrei Borzenkov > wrote: > >> On Fri, Sep 16, 2022 at 11:11 AM Antonio Murdaca >> 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. >> >> This implicitly adds >> >> After=test.service >> >> to default.target >> >> > 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 >> >> And systemd-boot-check-no-failures.service is ordered after >> default.target but before boot-complete.target. So you have an >> ordering loop (test.service has to be both Before and After >> default,target). >> > > Right, I understand the cycle, the issue is that it is not > clear/straightforward to rely on systemd-boot-check-no-failures.service and > another service that should only be started after boot-complete.service as > w/o DefaultDependencies=No we introduce the cycle. > > >> >> > 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. >> >> Yes, this is probably the only way. You may consider adding default >> dependencies explicitly if your service starts long running processes >> that need to be stopped on shutdown. >> > Re-adding dependencies on targets like shutdown for _any_ service that relates to boot-complete (in this case) seems weak too as it's not immediately clear why you need dd=no, I guess the relevant issue upstream describing something like this is https://github.com/systemd/systemd/issues/10210 > > Thanks for confirming this, although as somebody who followed > https://systemd.io/AUTOMATIC_BOOT_ASSESSMENT/#how-to-adapt-this-scheme-to-other-setups > what do you think about some official documentation/man page to help with > this? > > > -- > Antonio (runcom) Murdaca > Principal Software Engineer > B056 8311 87B3 DDEB 25B5 01AF CC5C 9A81 EDCA D821 > -- Antonio (runcom) Murdaca Principal Software Engineer B056 8311 87B3 DDEB 25B5 01AF CC5C 9A81 EDCA D821
Re: [systemd-devel] boot-complete.target dependencies issue
On Fri, Sep 16, 2022 at 11:38 AM Andrei Borzenkov wrote: > On Fri, Sep 16, 2022 at 11:11 AM Antonio Murdaca > 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. > > This implicitly adds > > After=test.service > > to default.target > > > 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 > > And systemd-boot-check-no-failures.service is ordered after > default.target but before boot-complete.target. So you have an > ordering loop (test.service has to be both Before and After > default,target). > Right, I understand the cycle, the issue is that it is not clear/straightforward to rely on systemd-boot-check-no-failures.service and another service that should only be started after boot-complete.service as w/o DefaultDependencies=No we introduce the cycle. > > > 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. > > Yes, this is probably the only way. You may consider adding default > dependencies explicitly if your service starts long running processes > that need to be stopped on shutdown. > Thanks for confirming this, although as somebody who followed https://systemd.io/AUTOMATIC_BOOT_ASSESSMENT/#how-to-adapt-this-scheme-to-other-setups what do you think about some official documentation/man page to help with this? -- Antonio (runcom) Murdaca Principal Software Engineer B056 8311 87B3 DDEB 25B5 01AF CC5C 9A81 EDCA D821
Re: [systemd-devel] boot-complete.target dependencies issue
On Fri, Sep 16, 2022 at 11:11 AM Antonio Murdaca 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. This implicitly adds After=test.service to default.target > 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 And systemd-boot-check-no-failures.service is ordered after default.target but before boot-complete.target. So you have an ordering loop (test.service has to be both Before and After default,target). > 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. Yes, this is probably the only way. You may consider adding default dependencies explicitly if your service starts long running processes that need to be stopped on shutdown.
