[systemd-devel] boot-complete.target dependencies issue

[Andrei Borzenkov]

On Fri, Sep 16, 2022 at 11:11 AM Antonio Murdaca <runcom at 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.