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

[johnlinp]

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]

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]

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]

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.

[johnlinp]

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

[johnlinp]

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