On Fri, Sep 16, 2022 at 11:48 AM Antonio Murdaca <runcom@xxxxxxxxxx> wrote:
On Fri, Sep 16, 2022 at 11:38 AM Andrei Borzenkov <arvidjaar@xxxxxxxxx> wrote:On Fri, Sep 16, 2022 at 11:11 AM Antonio Murdaca <runcom@xxxxxxxxxx> 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 EngineerB056 8311 87B3 DDEB 25B5 01AF CC5C 9A81 EDCA D821
Antonio (runcom) Murdaca
Principal Software Engineer
Principal Software Engineer
B056 8311 87B3 DDEB 25B5 01AF CC5C 9A81 EDCA D821
