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.
[systemd-devel] boot-complete.target dependencies issue
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. thanks! -- Antonio (runcom) Murdaca Principal Software Engineer B056 8311 87B3 DDEB 25B5 01AF CC5C 9A81 EDCA D821
