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

Fix arch systemd ordering cycle. #5819

Merged
merged 2 commits into from
Oct 18, 2024

Conversation

holmanb
Copy link
Member

@holmanb holmanb commented Oct 12, 2024

Proposed Commit Message

See individual commits. One is a fix for #5755 and the other cleans up redundant dependencies that were introduced in the single process change.

Merge type

  • Squash merge using "Proposed Commit Message"
  • Rebase and merge unique commits. Requires commit messages per-commit each referencing the pull request number (#<PR_NUM>)

@holmanb holmanb mentioned this pull request Oct 12, 2024
@holmanb holmanb changed the title Fix arch systemd Fix arch systemd ordering cycle. Oct 12, 2024
Copy link
Collaborator

@a-dubs a-dubs left a comment

Choose a reason for hiding this comment

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

CI is happy so i am happy :)

Thank you for adding detailed context in each commit message @holmanb.

Also I assume you would like to rebase and not squash (you have the squash merge checkbox selected atm)

Since After=sysinit.target is a default dependency, a cycle is
introduced when Before=sysinit.target and not DefaultDependencies=no.

Fixes canonicalGH-5755
A Before= on a single service doesn't need to exist in both
cloud-init-main.service and cloud-init-local.service, because
cloud-init-local.service and cloud-init-main.service are themselves
ordered. Only one requires it. The same applies for After=.
@TheRealFalcon
Copy link
Member

{% if variant in ["almalinux", "cloudlinux", "ubuntu", "unknown", "debian", "rhel"] %}
DefaultDependencies=no
{% endif %}
...
{% if variant in ["ubuntu", "unknown", "debian"] %}
Before=sysinit.target
{% endif %}

Should the rest of the OSes in the first section be extended to the 2nd section? Since it was part of the larger service file earlier, I would think yes for any distro that has DefaultDependencies=no

@TheRealFalcon
Copy link
Member

+1 to the 2nd commit

@holmanb
Copy link
Member Author

holmanb commented Oct 18, 2024

{% if variant in ["almalinux", "cloudlinux", "ubuntu", "unknown", "debian", "rhel"] %}
DefaultDependencies=no
{% endif %}
...
{% if variant in ["ubuntu", "unknown", "debian"] %}
Before=sysinit.target
{% endif %}

Should the rest of the OSes in the first section be extended to the 2nd section? Since it was part of the larger service file earlier, I would think yes for any distro that has DefaultDependencies=no

This ordering was inherited from cloud-init-local.service. I think that the answer is "yes", but I'd prefer to make service file cleanups in a separate PR.

Copy link
Member

@TheRealFalcon TheRealFalcon left a comment

Choose a reason for hiding this comment

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

LGTM! Thanks for the extra context.

@holmanb holmanb merged commit 0680d03 into canonical:main Oct 18, 2024
22 checks passed
holmanb added a commit that referenced this pull request Oct 18, 2024
Since After=sysinit.target is a default dependency, a cycle is
introduced when Before=sysinit.target and not DefaultDependencies=no.

Fixes GH-5755
holmanb added a commit to holmanb/cloud-init that referenced this pull request Oct 22, 2024
Since After=sysinit.target is a default dependency, a cycle is
introduced when Before=sysinit.target and not DefaultDependencies=no.

Fixes canonicalGH-5755
holmanb added a commit to holmanb/cloud-init that referenced this pull request Oct 22, 2024
A Before= on a single service doesn't need to exist in both
cloud-init-main.service and cloud-init-local.service, because
cloud-init-local.service and cloud-init-main.service are themselves
ordered. Only one requires it. The same applies for After=.
netcho pushed a commit to storpool/cloud-init that referenced this pull request Oct 24, 2024
A Before= on a single service doesn't need to exist in both
cloud-init-main.service and cloud-init-local.service, because
cloud-init-local.service and cloud-init-main.service are themselves
ordered. Only one requires it. The same applies for After=.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants