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

pid1: specifying DefaultDependencies=no in service unit causes default After= option lost in target unit #7113

Closed
johnlinp opened this issue Oct 17, 2017 · 5 comments

Comments

@johnlinp
Copy link
Contributor

commented Oct 17, 2017

Submission type

  • Bug report

systemd version the issue has been seen with

v235

Used distribution

Arch Linux

In case of bug report: Expected behaviour you didn't see

# systemctl list-dependencies --after some.target 
some.target
● └─some.service

In case of bug report: Unexpected behaviour you saw

# systemctl list-dependencies --after some.target 
some.target

In case of bug report: Steps to reproduce the problem

Create 2 units: some.service and some.target:

# cat some.service
[Unit]
DefaultDependencies=no

[Service]
ExecStart=/bin/sleep 5566

# cat some.target
[Unit]
Wants=some.service

According to systemd.target(5), the default After= dependency won't be applied if DefaultDependencies=no is specified in the target unit. However, in this case, DefaultDependencies=no is specified in the service unit. There is no description about this behavior in systemd.service(5).

@yuwata

This comment has been minimized.

Copy link
Member

commented Oct 18, 2017

I may misunderstand your point. But systemd.target(5) states that

Note that Wants= or Requires= must be defined in the target unit itself — if you for example define Wants=some.target in some.service, the automatic ordering will not be added.

So, I think in your example, the service unit should have Wants=some.target, instead of specifying Wants=some.service in the target unit.

No no, I was completely wrong. And you may be right.

See, https://github.com/systemd/systemd/blob/master/src/core/unit.c#L1194-L1198.

I do not know this implementation is right or not. But at least we need to revise systemd.target(5).

@johnlinp

This comment has been minimized.

Copy link
Contributor Author

commented Oct 18, 2017

From your link, I saw this behavior is since 21256a2. The commit message is:

unit: don't accidently create ordering links to targets when default deps are off for either target and unit

But I failed to see the real reason to do so.

@yuwata

This comment has been minimized.

Copy link
Member

commented Oct 18, 2017

After reconsideration, now I think this is a documentation issue. The meaning of DefaultDependencies=no is that only explicitly specified dependencies are enabled. In your example, if the target implicitly has After=some.service, then the service unit gains Before=some.target, but the rule is not explicitly specified. So, considering DefaultDependencies= settings not only in the target unit but also listed units (in your example, some.service) is desirable.
I've created PR #7120 which adds explanation about such a logic. If possible, please check it.

yuwata added a commit to yuwata/systemd that referenced this issue Oct 18, 2017

@johnlinp

This comment has been minimized.

Copy link
Contributor Author

commented Oct 18, 2017

I see. Thank you for the explanation and the fix!

@johnlinp johnlinp closed this Oct 18, 2017

@johnlinp

This comment has been minimized.

Copy link
Contributor Author

commented Oct 18, 2017

Since the pull request is not merged yet, it seems that I should reopen this issue. Sorry.

@johnlinp johnlinp reopened this Oct 18, 2017

keszybz added a commit that referenced this issue Oct 18, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
2 participants
You can’t perform that action at this time.