On Fri, Sep 16, 2022 at 11:38 AM Andrei Borzenkov <arvidj...@gmail.com> wrote:
> On Fri, Sep 16, 2022 at 11:11 AM 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. > > 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
