<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Sep 16, 2022 at 11:48 AM Antonio Murdaca <<a href="mailto:runcom@redhat.com">runcom@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Sep 16, 2022 at 11:38 AM Andrei Borzenkov <<a href="mailto:arvidjaar@gmail.com" target="_blank">arvidjaar@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Fri, Sep 16, 2022 at 11:11 AM Antonio Murdaca <<a href="mailto:runcom@redhat.com" target="_blank">runcom@redhat.com</a>> wrote:<br>
><br>
> Hi, following <a href="https://systemd.io/AUTOMATIC_BOOT_ASSESSMENT/#how-to-adapt-this-scheme-to-other-setups" rel="noreferrer" target="_blank">https://systemd.io/AUTOMATIC_BOOT_ASSESSMENT/#how-to-adapt-this-scheme-to-other-setups</a> 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.<br>
> I've taken from that blog this piece specifically:<br>
> ```<br>
> 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.<br>
> ```<br>
> So I've done the following with an example service and by enabling :<br>
><br>
> # cat /etc/systemd/system/test.service<br>
> [Unit]<br>
> Description="Order after boot-complete.target, pulling it in"<br>
> After=boot-complete.target<br>
> Requires=boot-complete.target<br>
><br>
> [Service]<br>
> Type=oneshot<br>
> ExecStart=/usr/bin/echo "Additional component that shall only run on boot success"<br>
> RemainAfterExit=yes<br>
><br>
> [Install]<br>
> WantedBy=default.target<br>
><br>
> # systemctl enable test.service  systemd-boot-check-no-failures.service<br>
> Created symlink /etc/systemd/system/default.target.wants/test.service → /etc/systemd/system/test.service.<br>
<br>
This implicitly adds<br>
<br>
After=test.service<br>
<br>
to default.target<br>
<br>
> 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.<br>
><br>
> # systemctl reboot<br>
><br>
> Unfortunately, the above results in:<br>
><br>
> systemd[1]: multi-user.target: Found ordering cycle on test.service/start<br>
> systemd[1]: multi-user.target: Found dependency on boot-complete.target/start<br>
> systemd[1]: multi-user.target: Found dependency on systemd-boot-check-no-failures.service/start<br>
<br>
And systemd-boot-check-no-failures.service is ordered after<br>
default.target but before boot-complete.target. So you have an<br>
ordering loop (test.service has to be both Before and After<br>
default,target).<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> systemd[1]: multi-user.target: Found dependency on multi-user.target/start<br>
> systemd[1]: multi-user.target: Job test.service/start deleted to break ordering cycle starting with multi-user.target/start<br>
><br>
> 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.<br>
<br>
Yes, this is probably the only way. You may consider adding default<br>
dependencies explicitly if your service starts long running processes<br>
that need to be stopped on shutdown.<br></blockquote></div></div></blockquote><div><br></div><div>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 <a href="https://github.com/systemd/systemd/issues/10210">https://github.com/systemd/systemd/issues/10210</a></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"></blockquote><div><br></div><div>Thanks for confirming this, although as somebody who followed <a href="https://systemd.io/AUTOMATIC_BOOT_ASSESSMENT/#how-to-adapt-this-scheme-to-other-setups" target="_blank">https://systemd.io/AUTOMATIC_BOOT_ASSESSMENT/#how-to-adapt-this-scheme-to-other-setups</a> what do you think about some official documentation/man page to help with this?</div></div><br clear="all"><div><br></div>-- <br><div dir="ltr"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr">Antonio (runcom) Murdaca<br>Principal Software Engineer</div><div dir="ltr"><span style="color:rgb(0,0,0)">B056 8311 87B3 DDEB 25B5  01AF CC5C 9A81 EDCA D821</span></div></div></div></div></div></div></div></div></div>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr">Antonio (runcom) Murdaca<br>Principal Software Engineer</div><div dir="ltr"><span style="color:rgb(0,0,0)">B056 8311 87B3 DDEB 25B5  01AF CC5C 9A81 EDCA D821</span></div></div></div></div></div></div></div></div></div>