debops / debops/debops

ifupdown : bookworm - bridge interfaces are down at boot

Open
#2,370 2 comments 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Jinja
Stars
1.4k
Forks
379
Avg merge
4d 18h
Merged PRs (30d)
8

Description

The bridge interfaces are broken with debops iface@.service on bookworm.

systemd 252.6-1
ifupdown 0.8.41

Current iface@.service from debops ifupdown:

  • on dhcp server:
systemd[1]: Started iface@br1.service - Bring network interface up for br1.
systemd[1]: Stopping iface@br1.service - Bring network interface up for br1...
ifdown[2085]: ifdown: waiting for lock on /run/network/ifstate.br1
sh[2133]: resolvconf: Error: Run lock held by another process for longer than 10 seconds
systemd[1]: iface@br1.service: Main process exited, code=exited, status=1/FAILURE
sh[2249]: Waiting for DAD... Done
sh[2305]: resolvconf: Error: Run lock held by another process for longer than 10 seconds
ifdown[2412]: resolvconf: Error: Run lock held by another process for longer than 10 seconds
ifdown[2473]: resolvconf: Error: Run lock held by another process for longer than 10 seconds
ifdown[2562]: Cannot find device "br1"
ifdown[2566]: Device "br1" does not exist.
ifdown[2570]: Cannot find device "br1"
systemd[1]: iface@br1.service: Failed with result 'exit-code'.
systemd[1]: Stopped iface@br1.service - Bring network interface up for br1.
  • on dhcp client:
systemd[1]: Started iface@br0.service - Bring network interface up for br0.
systemd[1]: Stopping iface@br0.service - Bring network interface up for br0...
ifdown[877]: ifdown: waiting for lock on /run/network/ifstate.br0
dhclient[888]: Internet Systems Consortium DHCP Client 4.4.3-P1
sh[888]: Internet Systems Consortium DHCP Client 4.4.3-P1
sh[888]: Copyright 2004-2022 Internet Systems Consortium.
sh[888]: All rights reserved.
sh[888]: For info, please visit https://www.isc.org/software/dhcp/
dhclient[888]: Copyright 2004-2022 Internet Systems Consortium.
dhclient[888]: All rights reserved.
dhclient[888]: For info, please visit https://www.isc.org/software/dhcp/
dhclient[888]: 
dhclient[888]: Listening on LPF/br0/9a:1a:61:e9:a3:8b
sh[888]: Listening on LPF/br0/9a:1a:61:e9:a3:8b
sh[888]: Sending on   LPF/br0/9a:1a:61:e9:a3:8b
sh[888]: Sending on   Socket/fallback
sh[888]: DHCPDISCOVER on br0 to 255.255.255.255 port 67 interval 5
dhclient[888]: Sending on   LPF/br0/9a:1a:61:e9:a3:8b
dhclient[888]: Sending on   Socket/fallback
dhclient[888]: DHCPDISCOVER on br0 to 255.255.255.255 port 67 interval 5
dhclient[888]: DHCPOFFER of 192.168.10.134 from 192.168.10.41
sh[888]: DHCPOFFER of 192.168.10.134 from 192.168.10.41
sh[888]: DHCPREQUEST for 192.168.10.134 on br0 to 255.255.255.255 port 67
dhclient[888]: DHCPREQUEST for 192.168.10.134 on br0 to 255.255.255.255 port 67
sh[888]: DHCPACK of 192.168.10.134 from 192.168.10.41
dhclient[888]: DHCPACK of 192.168.10.134 from 192.168.10.41
dhclient[888]: bound to 192.168.10.134 -- renewal in 27 seconds.
sh[888]: bound to 192.168.10.134 -- renewal in 27 seconds.
sh[950]: net.ipv6.conf.br0.accept_ra = 2
sh[994]: net.ipv6.conf.br0.accept_ra = 2
systemd[1]: iface@br0.service: Main process exited, code=exited, status=1/FAILURE
dhclient[1015]: Killed old client process
ifdown[1015]: Killed old client process
dhclient[1015]: Internet Systems Consortium DHCP Client 4.4.3-P1
ifdown[1015]: Internet Systems Consortium DHCP Client 4.4.3-P1
ifdown[1015]: Copyright 2004-2022 Internet Systems Consortium.
ifdown[1015]: All rights reserved.
ifdown[1015]: For info, please visit https://www.isc.org/software/dhcp/
dhclient[1015]: Copyright 2004-2022 Internet Systems Consortium.
dhclient[1015]: All rights reserved.
dhclient[1015]: For info, please visit https://www.isc.org/software/dhcp/
dhclient[1015]: 
dhclient[1015]: Listening on LPF/br0/9a:1a:61:e9:a3:8b
ifdown[1015]: Listening on LPF/br0/9a:1a:61:e9:a3:8b
ifdown[1015]: Sending on   LPF/br0/9a:1a:61:e9:a3:8b
ifdown[1015]: Sending on   Socket/fallback
dhclient[1015]: Sending on   LPF/br0/9a:1a:61:e9:a3:8b
dhclient[1015]: Sending on   Socket/fallback
dhclient[1015]: DHCPRELEASE of 192.168.10.134 on br0 to 192.168.10.41 port 67
ifdown[1015]: DHCPRELEASE of 192.168.10.134 on br0 to 192.168.10.41 port 67
ifdown[1065]: Device "br0" does not exist.
ifdown[1069]: Cannot find device "br0"
systemd[1]: iface@br0.service: Failed with result 'exit-code'.
systemd[1]: Stopped iface@br0.service - Bring network interface up for br0.

The issue can be reproduced after boot by first deleting the bridge interface with brctl delbr <bridge iface>.

If I remove from iface@.service BindsTo=sys-subsystem-net-devices-%i.device then the bridge loads fine at boot (note I also added an After=sys-subsystem-net-devices-%i.device in iface@.service):

  • dhcp server:
systemd[1]: Started iface@br1.service - Bring network interface up for br1.
sh[2228]: resolvconf: Error: Run lock held by another process for longer than 10 seconds
sh[2361]: Waiting for DAD... Done
sh[2559]: br1=br1
  • dhcp client:
systemd[1]: Started iface@br0.service - Bring network interface up for br0.
dhclient[893]: Internet Systems Consortium DHCP Client 4.4.3-P1
sh[893]: Internet Systems Consortium DHCP Client 4.4.3-P1
sh[893]: Copyright 2004-2022 Internet Systems Consortium.
sh[893]: All rights reserved.
sh[893]: For info, please visit https://www.isc.org/software/dhcp/
dhclient[893]: Copyright 2004-2022 Internet Systems Consortium.
dhclient[893]: All rights reserved.
dhclient[893]: For info, please visit https://www.isc.org/software/dhcp/
dhclient[893]: 
dhclient[893]: Listening on LPF/br0/9a:1a:61:e9:a3:8b
sh[893]: Listening on LPF/br0/9a:1a:61:e9:a3:8b
sh[893]: Sending on   LPF/br0/9a:1a:61:e9:a3:8b
sh[893]: Sending on   Socket/fallback
dhclient[893]: Sending on   LPF/br0/9a:1a:61:e9:a3:8b
sh[893]: DHCPDISCOVER on br0 to 255.255.255.255 port 67 interval 5
sh[893]: DHCPOFFER of 192.168.10.17 from 192.168.10.1
sh[893]: DHCPREQUEST for 192.168.10.17 on br0 to 255.255.255.255 port 67
dhclient[893]: Sending on   Socket/fallback
dhclient[893]: DHCPDISCOVER on br0 to 255.255.255.255 port 67 interval 5
dhclient[893]: DHCPOFFER of 192.168.10.17 from 192.168.10.1
dhclient[893]: DHCPREQUEST for 192.168.10.17 on br0 to 255.255.255.255 port 67
dhclient[893]: DHCPACK of 192.168.10.17 from 192.168.10.1
sh[893]: DHCPACK of 192.168.10.17 from 192.168.10.1
dhclient[893]: bound to 192.168.10.17 -- renewal in 40130 seconds.
sh[893]: bound to 192.168.10.17 -- renewal in 40130 seconds.
sh[985]: net.ipv6.conf.br0.accept_ra = 2
sh[1027]: net.ipv6.conf.br0.accept_ra = 2
sh[1037]: br0=br0
dhclient[893]: DHCPREQUEST for 192.168.10.17 on br0 to 192.168.10.1 port 67
dhclient[893]: DHCPACK of 192.168.10.17 from 192.168.10.1
dhclient[893]: bound to 192.168.10.17 -- renewal in 33401 seconds.

Somehow the br1 device is created on ifdown and is ifdown does not delete it. So later attempt to start iface@br1.service succeed:

systemd[1]: Started iface@br1.service - Bring network interface up for br1.
sh[8627]: Waiting for DAD... Done
sh[8724]: br1=br1

though this is a side effect.

The systemd behavior with regards to BindsTo is correct to me per:
https://github.com/systemd/systemd/pull/4733#issuecomment-262989671 "BindsTo= just means: whatever happens, don't permit A running if it has BindsTo=B and B isn't running. "
except maybe it should not even run stop if start ExecStart never ran.

I wonder how to proceed. We want BindsTo at least for non-virtual interfaces like bridges. You mentioned in https://www.reddit.com/r/debian/comments/7nw98g/comment/ds57s74/ "stick to ifupdown and ifup@.service but configure virtual network interfaces as needed in udev beforehand. I'm not sure how this should be done properly, maybe with aid of .device units that define these devices on boot. But this involves more moving parts and I didn't really check if that solution is viable."
I don't think one can create an interface with udev without binding it to a physical interface event (add, change, remove). So to me udev cannot help to create this bridge device before running iface@ service.
We could ask the systemd projects devs how they envision this bridge device creation (or if they have other ideas to cope with this issue).

Also, we may be able to create the bridge with brctl addbr <bridge iface> (I cannot seem to find how to do this with the newer bridge tool. But I cannot find how to get which interfaces are bridges before the bridge is created from ifupdown (ifquery). Thus I cannot tell which bridge interfaces to create via brctl.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reviewing the current iface@.service behavior and reproduce the failure after deleting the bridge with brctl delbr. Compare boot results with and without BindsTo=sys-subsystem-net-devices-%i.device, then determine how bridge interfaces should be created before ifupdown runs. Done means bridge interfaces reliably come up at boot for both DHCP server and client configurations.

Written by the indexing model from the issue text.

Assessment

Tech stack
ansible, debian, linux
Domain
infrastructure, networking, operating-systems
Issue type
Bug
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.