一次磁盘清理导致的docker启动失败

前言

近日想要在我的云服务器上安装graphviz时，发现我的根目录盘满了（直到现在也是快满的状态，服务商说根目录无法扩容🤔🤔🤔）

image-20220608191344505

于是通过逐层执行du -h --max-depth=1，我着手删除了一些比较占磁盘空间的文件

image-20220608191818424

并且顺手扩容了这台云主机的磁盘，reboot了一下，

然后我发现我的docker没有正常地自动启动，尝试手动启动也失败了

需要了解的词

• systemctl 用于控制systemd服务，类比k8s中的kubectl
• 软链接（symbolic link） 一个文件在某一路径下的同步链接（不重复占用磁盘空间，且实时同步）

Failed to get D-Bus connection

首先遇到的报错就是这个了

# systemctl start docker
Failed to get D-Bus connection: Operation not permitted

不多废话直接Google，但按大家描述的场景都是在docker容器内使用systemctl时出现的这种情况

image-20220612180413718

具体原因是systemd是需要特权(CAP_SYS_ADMIN)去访问Linux内核的；而容器并不是一个完整的操作系统，只有一个文件系统，并且默认启动的容器只是普通用户(non-privileged)这样的权限，是没有CAP_SYS_ADMIN权限的，所以自然就用不了systemctl

这里也许是因为我的云服务器服务商扩容或是重启时权限出错了，再次reboot后就正常了

Authorization not available

很快我又遇到了第二个报错

Authorization not available. Check if polkit service is running or see debug message for more information

google一番后找到了答案，是/var下的一些软链接被我错误清理了

The symbolic link between /run, /run/lock to /var/run, /var/lock respectively was removed which causes the service not to properly run.

重建这两个软链接后就恢复正常了

# mv /var/run /var/run.old
# mv /var/lock /var/lock.old
# ln -s /run /var/
# ln -s /run/lock /var/

最后验证下刚刚创建的软链接：

# ls -l /var/run
# ls -l /var/lock

期望的输出：

$ ls -l /var/run
lrwxrwxrwx. 1 root root 6 May 11 2022 /var/run -> ../run
$ ls -l /var/lock
lrwxrwxrwx. 1 root root 11 May 11 2016 /var/lock -> ../run/lock

同步下更改，然后重启服务器：

# sync; sync
# reboot

验证docker服务状态：

image-20220613010718288

至此一切恢复岁月静好

总结

以此契机深入了解了systemd服务，并且，不要乱删文件