systemd broken dependencies, ordering cycle, Unknown lvalue 'Require' in section 'Unit' about corridor HOT 11 CLOSED

1. broken dependencies

• https://lists.freedesktop.org/archives/systemd-devel/2016-July/037236.html
• https://lists.freedesktop.org/archives/systemd-devel/2016-July/037242.html

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

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

Ouch, fixed.

3. 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.

from corridor.

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

from corridor.

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?

from corridor.

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 )

from corridor.

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.

from corridor.

Why, what's so bad about it?

More difficult to get right and maintain in long run.

from corridor.

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

from corridor.

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

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

from corridor.

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.

from corridor.

Thanks for the link, makes sense.

from corridor.

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

from corridor.