Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

rauc: rauc-mark-good: disable implicit dependencies #307

Merged
merged 1 commit into from
Apr 16, 2024

Conversation

js731ca
Copy link
Contributor

@js731ca js731ca commented Mar 16, 2024

Having implicit dependencies enabled would lead to ordering cycles when enabling 'boot assessment', through
systemd-boot-check-no-failures [1], which is a service that forces the multi-user.target to be reached before the boot-complete.target.

The ordering cycle in this case would be:
boot-complete -requires-> systemd-boot-check-no-failures systemd-boot-check-no-failures -after-> multi-user rauc-mark-good -after-> boot-complete
boot-complete -after-> multi-user
multi-user -after-> rauc-mark-good

circle

Which systemd would break by simply not running rauc-mark-good.

The solution is to disable implicit dependencies that would otherwise add an 'After=rauc-mark-good.service' to the multi-user.target via the [Install] section.

Link: https://www.freedesktop.org/software/systemd/man/latest/systemd-boot-check-no-failures.html

Having implicit dependencies enabled would lead to ordering cycles
when enabling 'boot assessment', through
systemd-boot-check-no-failures [1], which is a service that forces the
multi-user.target to be reached before the boot-complete.target.

The ordering cycle in this case would be:
boot-complete -requires-> systemd-boot-check-no-failures
systemd-boot-check-no-failures -after-> multi-user
rauc-mark-good -after-> boot-complete
boot-complete -after-> multi-user
multi-user -after-> rauc-mark-good

Which systemd would break by simply not running rauc-mark-good.

The solution is to disable implicit dependencies that would otherwise
add an 'After=rauc-mark-good.service' to the multi-user.target via the
[Install] section.

Link: https://www.freedesktop.org/software/systemd/man/latest/systemd-boot-check-no-failures.html
Signed-off-by: Johannes Schneider <johannes.schneider@leica-geosystems.com>
@ejoerns
Copy link
Member

ejoerns commented Apr 15, 2024

Having implicit dependencies enabled would lead to ordering cycles when enabling 'boot assessment', through
systemd-boot-check-no-failures [1], which is a service that forces the multi-user.target to be reached before the boot-complete.target.

Even if not using the example systemd-boot-check-no-failures directly, it is probably a good blueprint to order multi-user.target before boot-complete.target, yes.

@js731ca thank you for diving into this.

The solution is to disable implicit dependencies that would otherwise add an 'After=rauc-mark-good.service' to the multi-user.target via the [Install] section.

I had to look this up, so for reference: this addresses systemd behavior that's described in https://www.freedesktop.org/software/systemd/man/latest/systemd.target.html#Default%20Dependencies

Setting DefaultDependencies=no sounds reasonable to me. An alternative would be not to use WantedBy=multi-user.target for installation. But I actually don't know a better option, yet.

@michaelolbrich maybe?

@js731ca
Copy link
Contributor Author

js731ca commented Apr 16, 2024

Setting DefaultDependencies=no sounds reasonable to me. An alternative would be not to use WantedBy=multi-user.target for installation. But I actually don't know a better option, yet.

@michaelolbrich maybe?

Btw: what also worked was using [Install] WantedBy=basic.target, since the service "just needs to be queued $somehow"... but the DefaultDependencies seemed cleaner to me

@michaelolbrich
Copy link

This looks like the correct solution to me. And the equivalent service from systemd (systemd-bless-boot.service) contains DefaultDependencies=no as well.

Copy link
Member

@ejoerns ejoerns left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@js731ca @michaelolbrich thanks for your opinions on this!

So we go for the DefaultDependencies=no solution.

FTR: CI fails due to the PR sitting on older master but the change itself cannot make CI fail, anyway.

@ejoerns ejoerns merged commit 4904f9f into rauc:master Apr 16, 2024
1 of 2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants