6

I have ran into a most annoying problem when rebooting/ shutting down. For some odd reason the shutdown always takes the "maximum" amount of time.

I have been able to trace the cause to be networking.service which times out at 90 seconds trying to bring down a bunch of interfaces. I suspect the same also causes something of an unnecessary delay when booting (about 30 seconds) but I can live with that.

My network consists of one physical interface, on top of which sits a few VLANs and bridges on top of those. Neither the physical interface nor the VLANs have any addresses associated with them, i.e. simply:

allow-hotplug enp2s0
iface enp2s0 inet manual

auto vlan2
iface vlan2 inet manual
    vlan_raw_device enp2s0

auto br2
iface br2 inet manual
    bridge_ports vlan2

The system itself does not have direct network access (no IPv4 addresses), but acts as a host to a virtual machine (hence the bridges) which then handles the networking. Everything works perfectly fine except for the shutdown.

Does anyone have any idea what could be causing this?

The shutdown log (from journalctl -b -1) shows the following:

Oct 03 09:09:25 myhostname systemd[1]: Deactivated swap /dev/disk/by-uuid/6db311a2-97ef-479c-8e35-d7f760c3d3b0.
Oct 03 09:09:25 myhostname kernel: br0: port 1(enp2s0) entered disabled state
Oct 03 09:09:25 myhostname kernel: br10: port 1(vlan10) entered disabled state
Oct 03 09:09:25 myhostname kernel: br3: port 1(vlan3) entered disabled state
Oct 03 09:09:25 myhostname kernel: br2: port 1(vlan2) entered disabled state
Oct 03 09:09:35 myhostname kernel: device vlan10 left promiscuous mode
Oct 03 09:09:35 myhostname kernel: br10: port 1(vlan10) entered disabled state
Oct 03 09:09:35 myhostname systemd[1]: Stopped ifup for enp2s0.
Oct 03 09:09:35 myhostname systemd[1]: Stopped ifup for enp3s0.
Oct 03 09:09:35 myhostname kernel: IPv6: ADDRCONF(NETDEV_UP): vlan10: link is not ready
Oct 03 09:09:45 myhostname ifdown[5961]: Removed VLAN -:vlan10:-
Oct 03 09:09:55 myhostname ifdown[5961]: Removed VLAN -:vlan6:-
Oct 03 09:10:05 myhostname ifdown[5961]: Removed VLAN -:vlan5:-
Oct 03 09:10:15 myhostname kernel: device vlan3 left promiscuous mode
Oct 03 09:10:15 myhostname kernel: br3: port 1(vlan3) entered disabled state
Oct 03 09:10:15 myhostname kernel: IPv6: ADDRCONF(NETDEV_UP): vlan3: link is not ready
Oct 03 09:10:25 myhostname ifdown[5961]: Removed VLAN -:vlan3:-
Oct 03 09:10:35 myhostname kernel: device vlan2 left promiscuous mode
Oct 03 09:10:35 myhostname kernel: br2: port 1(vlan2) entered disabled state
Oct 03 09:10:35 myhostname kernel: IPv6: ADDRCONF(NETDEV_UP): vlan2: link is not ready
Oct 03 09:10:45 myhostname ifdown[5961]: Removed VLAN -:vlan2:-
Oct 03 09:10:55 myhostname systemd[1]: networking.service: Stopping timed out. Terminating.
Oct 03 09:10:55 myhostname systemd[1]: networking.service: Control process exited, code=killed status=15

So clearly there is something weird going on. I am running Debian 9.5.

  • Welcome, ifup and ifdown will configure the network interfaces under /etc/network/interfaces , it will take a few moments. Keep only lo configured to see the difference. – GAD3R Oct 3 '18 at 8:07
  • 2
    That's the questioner's question GAD3R: why ifdown is taking 10 seconds per VLAN interface. (10 network interfaces, seemingly vlan1 to vlan10, times 10s per interface is more than the 90s timeout.) The questioner is probably also curious why a system with "one physical interface" and networking managed by networking.service has systemd telling it about stopping individual ifup services for enp2s0 and enp3s0. – JdeBP Oct 3 '18 at 8:20
  • Yes, that they do, but the question is why does removing a simple VLAN interface take 10 seconds each? Could this be a matter of strange ordering somehow? – Teemu Karimerto Oct 3 '18 at 8:20
  • @JdeBP There are actually two physical interfaces, but the enp3s0 is likely not the cause of the slowdown as it is configured normally with a local 192.168.x.x address only. Apologies for the confusion! – Teemu Karimerto Oct 3 '18 at 8:23
  • I've been booting the system and trying to make this work with little success so far. However there was one fairly successful boot where all interfaces were brought down within one second, though I have no idea why that happened as I did not change anything. – Teemu Karimerto Oct 4 '18 at 12:32
2

After days of googling and reading a bazillion different mailing lists, forums, posts and whatnot, I finally found the answer. The slow shutdown / reboot (and equally an unnecessary ~30 second delay in boot up) was caused by the ancient relic known as avahi-daemon. It turns out that this was called for every single interface already removed from the system and thus the command/script timing out after 10 seconds.

Removing the aforementioned package fixed everything and all is running smooth now. Shutdown takes mere seconds and a full reboot until virtual guests are also up and running is well under two minutes.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.