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). > 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.
