12

According to systemd-analyze blame, networking-service is taking over 5 minutes to start at boot:

systemd-analyze blame

Why is this happening and how can I fix it?

Zanna
  • 70,465
Alexandre Liscia
  • 223

4 Answers4

21

Edit /etc/network/interfaces and change "auto" for interfaces to "allow-hotplug"

sudo nano /etc/network/interfaces

Example: auto interface for ethernet card auto eth0 change to allow-hotplug eth0

After that for me "systemd-analyze blame" -> networking.service changes from 5 min to 41 s

user3055379
  • 311
8

I came up with a solution, though it may be more appropriate to call it a workaround.

The problem is that the networking.service has a default timeout of 5 minutes, and for whatever reason, the full timeout period must expire before the boot continues. So, boot takes a little more than 5 minutes.

The solution I came up with is to do the following:

 sudo systemctl edit networking.service

Add the following line:

TimeoutStartSec=10sec

I still have no idea on root cause, and what exactly it is that's timing out, but reducing the timeout from 5 minues to 10 seconds makes the boot up run quite fast, for obvious reasons.

Here's a link to my solution on Ubuntu Forums: https://ubuntuforums.org/showthread.php?t=2342450&p=13569192#post13569192

Hope that helps.

mez.pahlan
  • 212
Mark J. Bobak
  • 143
  • 3
    Do not edit /lib/systemd/system/networking.service directly. Use systemctl edit networking.service instead. Or your edits will be overwritten the next time whichever package provides that file is upgraded. – muru Dec 06 '16 at 01:46
  • 2
    That does't work me. When editing the file with sudo systemctl edit networking.service it still takes 5min to boot. /lib/systemd/system/networking.service shows TimeoutStartSec=5min – rob Jul 20 '18 at 19:58
  • You're still on 16.10? I'm on 18.04 LTS, and this is no longer an issue for me. – Mark J. Bobak Jul 30 '18 at 17:32
  • 3
    The answer about changing auto to allow-hotplug is the correct one, this is allowing the networking service to skip interfaces if they are not available at that point in time. Any interface listed as auto causes the networking service to wait until it's up or the timeout is hit. – David Schoen Jan 13 '19 at 04:28
1

Just adding TimeoutStartSec=10sec didn't work for me - I had to make one slight change. Looking at /lib/systemd/system/networking.service I saw that config attribute was nested under [Service]

I edited /etc/systemd/system/networking.service.d/override.conf to look like the following:

[Service]
TimeoutStartSec=10sec

And now it works

JD Wolk
  • 11
0

From what I found maybe it would be appropriate to find a better underlying cause. In my case it seems to be systemd-networkd.service that is stalling the process and still further it is a specific network interface that stalls networkd.

So I decided on two approaches:

  1. Simply time-out the systemd-networkd-wait-online.service after a much more user friendly time. This can be achieved by editing /lib/systemd/system/systemd-networkd-wait-online and adding an option to the ExecStart line that calls the service. To simply time-out faster append --timeout=10, to reduce the wait time to 10s. It is 120S by default. However this might IMHO not be the best approach, maybe it is critical that some interface is indeed available.

    ExecStart=/lib/systemd/systemd-networkd-wait-online --timeout=10

  2. Try ignoring an interface you think might be the root cause. In my case this was a non critical wireless link that I had not yet configured properly. It was defined in netplan yaml file, but I had not yet set-up wpa_supplicant to get it up and running as AP with IP etc. This was the dependency that caused the stall. So I appended --ignore=int_wlan0 to the ExecStart line. Sure enough, the critical ethernet interfaces had come-up very quickly but networkd was waiting for something more from the WLAN link. Once the ignore was in place, bootup jumped directly throught the 2min delay.

    ExecStart=/lib/systemd/systemd-networkd-wait-online --ignore=int_wlan0

This makes some sense as "man systemd-networkd-wait-online.service" states that "it will wait for all links it is aware of and which are managed by systemd-networkd.service(8) to be fully configured or failed". What networkd considers to be fully configured is an open question. It seems from my set-up this includes having an IP address, but this may be just a special case for wireless links. I don't know. However this fix got things running much faster and at least I know the only dependency was the wireless link.

Aidan Walton
  • 21