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.

Sign up for GitHub

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

Jump to bottom

systemd broken dependencies, ordering cycle, Unknown lvalue 'Require' in section 'Unit' #29

Closed
adrelanos opened this issue Jul 29, 2016 · 11 comments
Closed

systemd broken dependencies, ordering cycle, Unknown lvalue 'Require' in section 'Unit' #29

adrelanos opened this issue Jul 29, 2016 · 11 comments

Comments

@adrelanos
Copy link
Contributor

  1. broken dependencies
  1. Unknown lvalue 'Require' in section 'Unit'
Jul 29 16:22:22 localhost systemd[1]: [/lib/systemd/system/qubes-misc-post.service.d/corridor.conf:2] Unknown lvalue 'Require' in section 'Unit'
Jul 29 16:22:22 localhost systemd[1]: [/lib/systemd/system/qubes-network.service.d/corridor.conf:2] Unknown lvalue 'Require' in section 'Unit'
Jul 29 16:22:22 localhost systemd[1]: [/lib/systemd/system/qubes-netwatcher.service.d/corridor.conf:2] Unknown lvalue 'Require' in section 'Unit'
  1. dependency cycle

(not a Debian issue)

Jul 29 16:22:22 localhost systemd[1]: Found ordering cycle on basic.target/start
Jul 29 16:22:22 localhost systemd[1]: Found dependency on sysinit.target/start
Jul 29 16:22:22 localhost systemd[1]: Found dependency on networking.service/start
Jul 29 16:22:22 localhost systemd[1]: Found dependency on network-pre.target/start
Jul 29 16:22:22 localhost systemd[1]: Found dependency on corridor-init-forwarding.service/start
Jul 29 16:22:22 localhost systemd[1]: Found dependency on qubes-iptables.service/start
Jul 29 16:22:22 localhost systemd[1]: Found dependency on basic.target/start
Jul 29 16:22:22 localhost systemd[1]: Breaking ordering cycle by deleting job networking.service/start
Jul 29 16:22:22 localhost systemd[1]: Job networking.service/start deleted to break ordering cycle starting with basic.target/start
rustybird pushed a commit that referenced this issue Jul 30, 2016
Use autoconf-like @sbin@
f8708d4 
#29
rustybird pushed a commit that referenced this issue Jul 30, 2016
Requires=, not Require=
cfaabc5 
#29
@rustybird
Copy link
Owner

rustybird commented Jul 30, 2016 •
edited
Loading

  1. broken dependencies

What are you referring to? Lennart said the dependencies are correct. (If you're talking about the SBIN confusion, I've changed it to @SBIN@ so it's more obvious that this is a variable.)

  1. Unknown lvalue 'Require' in section 'Unit'

Ouch, fixed.

  1. dependency cycle

That's a bug in qubes-iptables.service (also, dnf-makecache.timer and yum-makecache.timer), where WantedBy=basic.target is set but DefaultDependencies=no is missing.

@adrelanos
Copy link
Contributor Author

(--> QubesOS/qubes-issues#2209)

In https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=832802 I posted a similar systemd service file. One with WantedBy=multi-user.target with After=network-pre.target and Wants=network-pre.target. I was told in such cases one has to use DefaultDependencies=no. [I think he mistyped, because "DefaultDependencies=yes" is the default.]

I did sudo systemctl mask qubes-iptables and rebooted. Still got a systemd ordering cycle.

Jul 30 16:40:25 localhost systemd[1]: Found ordering cycle on basic.target/start
Jul 30 16:40:25 localhost systemd[1]: Found dependency on sysinit.target/start
Jul 30 16:40:25 localhost systemd[1]: Found dependency on networking.service/start
Jul 30 16:40:25 localhost systemd[1]: Found dependency on network-pre.target/start
Jul 30 16:40:25 localhost systemd[1]: Found dependency on corridor-init-forwarding.service/start
Jul 30 16:40:25 localhost systemd[1]: Found dependency on basic.target/start
Jul 30 16:40:25 localhost systemd[1]: Breaking ordering cycle by deleting job networking.service/start
Jul 30 16:40:25 localhost systemd[1]: Job networking.service/start deleted to break ordering cycle starting with basic.target/start

@rustybird
Copy link
Owner

Ah, Debian's networking.service orders itself after network-pre.target but before sysinit.target. I suppose corridor-init-forwarding.service should use DefaultDependencies=no, have you tested this?

@adrelanos
Copy link
Contributor Author

Rusty Bird:

Ah, Debian's networking.service orders itself after
network-pre.target but before sysinit.target.

I have no /lib/systemd/system/networking.service.

However, /lib/systemd/system/networking.service.d/network-pre.conf is owned by the systemd package.

dpkg -S /lib/systemd/system/networking.service.d/network-pre.conf 

systemd: /lib/systemd/system/networking.service.d/network-pre.conf

cat /lib/systemd/system/networking.service.d/network-pre.conf 

[Unit]
After=network-pre.target

systemctl show -p After,Before,Wants,Requires,RequiresOverridable \
>                -p Requisite,RequisiteOverridable,BindsTo,PartOf   \
>                -p Conflicts,DefaultDependencies networking.service

Requires=
RequiresOverridable=
Requisite=
RequisiteOverridable=
Wants=network.target system.slice
BindsTo=
PartOf=
Conflicts=shutdown.target
Before=sysinit.target shutdown.target network.target
After=mountkernfs.service local-fs.target systemd-random-seed.service network-pre.target systemd-journald.socket system.slice
DefaultDependencies=no

I suppose
corridor-init-forwarding.service should use DefaultDependencies=no,

Probably.

have you tested this?

No. ( And I would hope, and trying hard, DefaultDependencies=no could be avoided. )

No, but I am still experimenting with all of this for Qubes-Whonix purposes and trying to figure out if this is something Debian specific? A Debian bug? Or systemd bug? ( https://phabricator.whonix.org/T528 )

@rustybird
Copy link
Owner

And I would hope, and trying hard, DefaultDependencies=no could be avoided.

Why, what's so bad about it?

No, but I am still experimenting with all of this for Qubes-Whonix purposes and trying to figure out if this is something Debian specific? A Debian bug? Or systemd bug?

Looks like the systemd manpages don't specify that network-pre.target, if pulled in, should be reached as part of "basic system initialization", but networking.service assumes that it is.

@adrelanos
Copy link
Contributor Author

Why, what's so bad about it?

More difficult to get right and maintain in long run.

@rustybird
Copy link
Owner

I have no /lib/systemd/system/networking.service

It's generated from the SysV init script: systemctl show networking.service

And I would hope, and trying hard, DefaultDependencies=no could be avoided.

More difficult to get right and maintain in long run.

Eh, corridor-init-forwarding only uses ipset/iptables/sysctl. Should be fine, I'll try it on my end soon. Though if you have the time to try DefaultDependencies=no on Debian, I'd still appreciate it. (No worries if not.)

@rustybird
Copy link
Owner

It's generated from the SysV init script: systemctl show networking.service

... never mind, I see you've checked that already

rustybird pushed a commit that referenced this issue Jul 31, 2016
Break qubes-iptables.service's cycle
4789543 
#29
@adrelanos
Copy link
Contributor Author

I will test this soon(ish).

Btw http://lists.alioth.debian.org/pipermail/pkg-systemd-maintainers/2016-July/012257.html says this is not Debian specific.

@rustybird
Copy link
Owner

Thanks for the link, makes sense.

@adrelanos
Copy link
Contributor Author

Works for me. systemd no longer reports an ordering cycle.

This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@adrelanos @rustybird