Boot taking a long time

[Tom H]

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.

Indeed.


> 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 "@"
> character.
> 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
network:
  bonds:
    bond0:
      interfaces:
        - dummy0
        - dummy1
      addresses:
        - 192.168.0.9/24
      gateway4: 192.168.0.1
      dhcp4: no
      dhcp6: no
      parameters:
        mode: active-rr
  ethernets:
    dummy0:
      dhcp4: no
    dummy1:
      dhcp4: no


/etc/netplan # netplan generate


/etc/netplan # cd /run/systemd/network


/run/systemd/network # ls
10-netplan-bond0.netdev  10-netplan-bond0.network
10-netplan-dummy0.network  10-netplan-dummy1.network


/run/systemd/network # cat *
[NetDev]
Name=bond0
Kind=bond

[Bond]
Mode=active-rr
[Match]
Name=bond0

[Network]
LinkLocalAddressing=ipv6
Address=192.168.0.9/24
Address=192.168.0.9/24
Gateway=192.168.0.1
ConfigureWithoutCarrier=yes
[Match]
Name=dummy0

[Network]
LinkLocalAddressing=no
Bond=bond0
[Match]
Name=dummy1

[Network]
LinkLocalAddressing=no
Bond=bond0


/run/systemd/network #


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
boot process.

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
happens.

Anything in the output of "journalctl"? Or 'systemctl status
systemd-networkd-wait-online.service"?