因为自己毕业了，回头来就不能继续白捡腾讯云的1元学生机了。于是自己就捡了一个AMD EPYC处理器的SA1系列来继续托管站点。习惯每周都上去apt-get upgrade然后重启机器的我，发觉机器重启异常地慢。原本只需要30秒不到的，现在竟然需要一两分钟。于是我就此进行了一回排查。
这里的重启速度，是对比今年5月多我还没有把服务容器化、从S1实例上迁移过来的。所以可以不负责任地猜测，有几个不可避免的因素影响了开机时间：
- 容器化，docker的启停影响开机进度；
- SA1实例启动本来就慢一点；
- 腾讯给的镜像改了一些神奇的地方；
- ……
直到有一次，我看输入reboot之后半天机器都起不来，就上了VNC界面，就看到有类似的提示：
A start job is running for Wait for Network to be Configured发现“小霸王”
然后一看，好样的，完美地卡住了这个启动过程。翻查了一下，是一个叫做systemd-networkd-wait-online.service的服务卡了，只能等到超时。
加入Drop-In测试
于是，我一不做二不休加上了一个Drop-In来限制时间：
# sudo systemctl edit systemd-networkd-wait-online.service
# 输入
[Service]
TimeoutStartSec=30然后重启一看，傻眼了，差别只在2min30s和30s的区别。这个服务依旧像个“小霸王”一样顽固地卡在这。
深入networkctl
由于Ubuntu 18.04用的systemd-networkd来托管网络服务，尝试使用命令networkctl，发现eth0上的状态卡在了configuring（然而事实上是通的）：
网上很多人解决的方式就是把这个“小霸王服务”给mask了，不让它卡住。然而对于有网络业务的自启动应用来说，必须要确保网络正常配置才能运行。
IPv6禁用的影响？
这时候我看到了一个issue，就是在IPv6被禁用之后networkctl看到的连接一直是configuring：https://github.com/coreos/bugs/issues/1419 。这时，不妨联想到，国内常见云主机的IPv6在镜像里面默认都是被关闭的。所以不妨在/etc/sysctl.conf里面把它打开：
这里把关于disable_ipv6 = 1的改为0即可，然后sysctl -p生效。这时候可以看到networkctl已经变成了configured了：
验证改善结果
此时，重启试试，输入systemd-analyze blame，可以看到这个“小霸王”已经被去除了，启动瞬间提速：
备选方案与思考
对于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），外加上国人教程写得真的很粗暴，所以中途拐的弯还是比较多的。
最后一点，勤于思考，共勉吧！