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

[Antonio Murdaca]

On Fri, Sep 16, 2022 at 11:48 AM Antonio Murdaca <runcom at redhat.com> wrote:

>
>
> 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.
>>
>
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 Engineer
> B056 8311 87B3 DDEB 25B5 01AF CC5C 9A81 EDCA D821
>


-- 
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/fa0af431/attachment-0001.htm>