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

Simplify systemd service files #5830

Merged
merged 5 commits into from
Oct 18, 2024
Merged

Conversation

holmanb
Copy link
Member

@holmanb holmanb commented Oct 18, 2024

Additional Context

#5818

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>)

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!

- RHEL family distros use ds-identify, and therefore the run directory is
  already made and ds-identify will have created the enabled file.
- network.service doesn't appear to ever have been used, and was probably
  intended to be network.target.
This service is also Before=network-pre.target.
NetworkManager.service is ordered After=network-pre.target
Therefore, this setting is redundant.
This is required by all distros which use DefaultDependencies=no.
It implicitly added by all distros which do not use DefaultDependencies=no.
Therefore, it does no harm to apply it in all cases.
- There is no harm in ordering after a service which doesn't exist.
- Cloud-init's final stage should consistently be ordered with respect to
  multi-user.target on all distros.
@holmanb holmanb merged commit d1d7af6 into canonical:main Oct 18, 2024
21 of 22 checks passed
holmanb added a commit that referenced this pull request Oct 18, 2024
- RHEL family distros use ds-identify, and therefore the run directory is
  already made and ds-identify will have created the enabled file.
- network.service doesn't appear to ever have been used, and was probably
  intended to be network.target.
holmanb added a commit that referenced this pull request Oct 18, 2024
This service is also Before=network-pre.target.
NetworkManager.service is ordered After=network-pre.target
Therefore, this setting is redundant.
holmanb added a commit that referenced this pull request Oct 18, 2024
This is required by all distros which use DefaultDependencies=no.
It implicitly added by all distros which do not use DefaultDependencies=no.
Therefore, it does no harm to apply it in all cases.
holmanb added a commit that referenced this pull request Oct 18, 2024
- There is no harm in ordering after a service which doesn't exist.
- Cloud-init's final stage should consistently be ordered with respect to
  multi-user.target on all distros.
holmanb added a commit to holmanb/cloud-init that referenced this pull request Oct 22, 2024
- RHEL family distros use ds-identify, and therefore the run directory is
  already made and ds-identify will have created the enabled file.
- network.service doesn't appear to ever have been used, and was probably
  intended to be network.target.
holmanb added a commit to holmanb/cloud-init that referenced this pull request Oct 22, 2024
This service is also Before=network-pre.target.
NetworkManager.service is ordered After=network-pre.target
Therefore, this setting is redundant.
holmanb added a commit to holmanb/cloud-init that referenced this pull request Oct 22, 2024
This is required by all distros which use DefaultDependencies=no.
It implicitly added by all distros which do not use DefaultDependencies=no.
Therefore, it does no harm to apply it in all cases.
holmanb added a commit to holmanb/cloud-init that referenced this pull request Oct 22, 2024
- There is no harm in ordering after a service which doesn't exist.
- Cloud-init's final stage should consistently be ordered with respect to
  multi-user.target on all distros.
holmanb added a commit to holmanb/cloud-init that referenced this pull request Oct 22, 2024
netcho pushed a commit to storpool/cloud-init that referenced this pull request Oct 24, 2024
- RHEL family distros use ds-identify, and therefore the run directory is
  already made and ds-identify will have created the enabled file.
- network.service doesn't appear to ever have been used, and was probably
  intended to be network.target.
netcho pushed a commit to storpool/cloud-init that referenced this pull request Oct 24, 2024
This service is also Before=network-pre.target.
NetworkManager.service is ordered After=network-pre.target
Therefore, this setting is redundant.
netcho pushed a commit to storpool/cloud-init that referenced this pull request Oct 24, 2024
This is required by all distros which use DefaultDependencies=no.
It implicitly added by all distros which do not use DefaultDependencies=no.
Therefore, it does no harm to apply it in all cases.
netcho pushed a commit to storpool/cloud-init that referenced this pull request Oct 24, 2024
- There is no harm in ordering after a service which doesn't exist.
- Cloud-init's final stage should consistently be ordered with respect to
  multi-user.target on all distros.
netcho pushed a commit to storpool/cloud-init that referenced this pull request Oct 24, 2024
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.

2 participants