systemd-networkd-wait-online拖慢Ubuntu

这里的重启速度，是对比今年5月多我还没有把服务容器化、从S1实例上迁移过来的。所以可以不负责任地猜测，有几个不可避免的因素影响了开机时间：

容器化，docker的启停影响开机进度；
SA1实例启动本来就慢一点；
腾讯给的镜像改了一些神奇的地方；
……

直到有一次，我看输入reboot之后半天机器都起不来，就上了VNC界面，就看到有类似的提示：

A start job is running for Wait for Network to be Configured

发现“小霸王”

然后一看，好样的，完美地卡住了这个启动过程。翻查了一下，是一个叫做systemd-networkd-wait-online.service的服务卡了，只能等到超时。
systemd-networkd-wait-online服务超时

加入Drop-In测试

于是，我一不做二不休加上了一个Drop-In来限制时间：

sudo systemctl edit systemd-networkd-wait-online.service 
# 输入 
[Service] TimeoutStartSec=30

然后重启一看，傻眼了，差别只在2min30s和30s的区别。这个服务依旧像个“小霸王”一样顽固地卡在这。

卡住时的systemd时间统计

深入networkctl

由于Ubuntu 18.04用的systemd-networkd来托管网络服务，尝试使用命令networkctl，发现eth0上的状态卡在了configuring（然而事实上是通的）：
eth0网络接口卡在configuring

网上很多人解决的方式就是把这个“小霸王服务”给mask了，不让它卡住。然而对于有网络业务的自启动应用来说，必须要确保网络正常配置才能运行。

IPv6禁用的影响？

这时候我看到了一个issue，就是在IPv6被禁用之后networkctl看到的连接一直是configuring：https://github.com/coreos/bugs/issues/1419 。这时，不妨联想到，国内常见云主机的IPv6在镜像里面默认都是被关闭的。所以不妨在/etc/sysctl.conf里面把它打开：
启用IPv6

这里把关于disable_ipv6 = 1的改为0即可，然后sysctl -p生效。这时候可以看到networkctl已经变成了configured了：
networkctl的网络显示configured
验证改善结果

此时，重启试试，输入systemd-analyze blame，可以看到这个“小霸王”已经被去除了，启动瞬间提速：

优化后的systemd时间统计

备选方案与思考

对于Ubuntu 18.04使用systemd-networkd管理网络的方式，在配置云主机时，具体流程是这样的：

cloud-init生成一份netplan的配置文件，放在/etc/netplan中；
netplan apply时操作systemd-networkd，生成对应的内部运行时配置。

问题在于，刚刚给出来的解决方案是启用内核的IPv6支持，因为这边的yaml文件里面描述的只有IPv4的内容，而没有不配置IPv6的内容。

network:
    version: 2
    ethernets:
        eth0:
            dhcp4: true
            match:
                macaddress: 52:54:00:xx:xx:xx
            set-name: eth0

在翻阅GitHub issue时，看到了这样一种解决方案：https://github.com/systemd/systemd/issues/6441#issuecomment-480052388 。在网卡配置下彻底禁止配置IPv6，这样就可以阻止在IPv6禁用的条件下对IPv6尝试配置与配置检查。

   dhcp6: false
        accept-ra: no
        link-local: [ ]

后记

这次的手记，主要是在自己用中英文搜索若干资料后，才测试、总结出来的。这个坑可能平时我们都想不到（毕竟是高贵的Systemd），外加上国人教程写得真的很粗暴，所以中途拐的弯还是比较多的。

最后一点，勤于思考，共勉吧！