Boot taking a long time
tomh0665 at gmail.com
Sat Nov 3 21:48:42 UTC 2018
On Sat, Nov 3, 2018 at 4:17 PM Paul Groves <paul.groves.787 at gmail.com> wrote:
> On 03/11/2018 10:26, Tom H wrote:
>> What's the unit that's blocking?
>> Check with "systemd-analyze blame" and "systemd-analyze critical-chain
>> [<unit>]" where/why the delay is.
>> You might also want to add "systemd.log_level=debug" to your kernel
>> cmdline in irder to get more logs.
> The last boot for some reason was quicker at around 1 and a half mins.
> It can be anywhere from about this to 3 and a half mins.
> See below the output of those two commands. It seems that
> systemd-networkd-wait-online.service is the problem.
> I will have to arrange downtime to reboot the system and change the
> kernel parameters. Although the problem is easily replicable. All that
> needs to be done is install Ubuntu 18.04.1 Server from the normal ISO
> and configure a network bond. Then this happens.
> It doesn't happen when you just have a normally configured interface
> though, so I am wondering if it is where the interfaces eno1 and enp2s0
> are disabled in netplan due to being slaves to bond0 the system is
> waiting for them to come up, but of course they never do.
> Is there a way in netplan of saying that an interface is optional?
> paul at web:~$ systemd-analyze blame
> 1min 4.712s systemd-networkd-wait-online.service
> paul at web:~$ systemd-analyze critical-chain
> The time after the unit is active or started is printed after the "@"
> The time the unit takes to start is printed after the "+" character.
> graphical.target @1min 59.079s
> └─multi-user.target @1min 59.079s
> └─apache2.service @1min 35.369s +23.709s
> └─basic.target @1min 34.917s
> └─sockets.target @1min 34.915s
> └─lxd.socket @1min 34.890s +23ms
> └─sysinit.target @1min 34.735s
> └─cloud-init.service @1min 33.499s +1.182s
> └─systemd-networkd-wait-online.service @28.784s +1min 4.712s
> └─systemd-networkd.service @28.703s +74ms
> └─network-pre.target @28.701s
> └─cloud-init-local.service @5.109s +23.590s
> └─systemd-remount-fs.service @4.509s +594ms
> └─systemd-journald.socket @4.374s
> └─system.slice @4.362s
> └─-.slice @4.349s
I set up a similar netplan config.
/etc/netplan # vi ubu.yaml
/etc/netplan # cat ubu.yaml
/etc/netplan # netplan generate
/etc/netplan # cd /run/systemd/network
/run/systemd/network # ls
/run/systemd/network # cat *
bond0.network somehow ends up with two "Address=" address lines. I
haven't seen this before but this might be an 18.10 or 19.04 problem
rather than an 18.04 one. But I don't see why that would slow down the
You could try copying the .network and .netdev files to
"/etc/systemd/network/" (and edit them, perhaps by removing the
LinkLocalAddressing and ConfigureWithoutCarrier to simplify
everything; even though they don't look like they'd slow anything
down) and move the yaml file out of "/etc/netplan/" to see what
Anything in the output of "journalctl"? Or 'systemctl status
More information about the ubuntu-users