[systemd-devel] boot-complete.target dependencies issue
Antonio Murdaca
runcom at redhat.com
Fri Sep 16 09:48:26 UTC 2022
On Fri, Sep 16, 2022 at 11:38 AM Andrei Borzenkov <arvidjaar at gmail.com>
wrote:
> 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).
>
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20220916/a7da2456/attachment.htm>
More information about the systemd-devel
mailing list