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?

Improve this question
0

4 Answers 4

Reset to default
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

Improve this answer
4
  • 1
    this save my day :)
    – Blau
    Oct 5, 2018 at 9:52
  • This also worked on Ubuntu 18.04, and reduced networking.service time from 47 seconds to 1 second. I noticed it in the boot messages (though not the dmesg log) when it got stuck, saying "A start job is running for Raise network interfaces".
    – Wade Walker
    Apr 23, 2019 at 18:26
  • This worked for me on Ubuntu 18.04.4 with kernel 5.5.0-050500-generic 64-bit; Qualcomm card Dell XPS 13
    – thedoctar
    Mar 7, 2020 at 23:45
  • You just saved me 15 mins on every boot <3
    – AH.Pooladvand
    Apr 20 at 17:11
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.

Improve this answer
4
  • 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 6, 2016 at 1: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, 2018 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, 2018 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, 2019 at 4: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

Improve this answer
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.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .