上周好多个快照博主都没有更新。然后 20180120 快照出来的时候刚好是周日，就更新了一下。结果重启进入系统的时候「卡」在了「Started Command Scheduler」那里（禁用了 Plymouth 所以一直看的就是启动时候的一行行回馈信息）。开始以为是系统无法进入桌面了，后来发现是因为当时 BtrFS 文件系统的「再平衡（btrfs-balance）」操作在运行，导致系统无响应。

而这一切都是因为在 0120 快照的时候 BtrFS 的文件系统维护软件包 btrfsmaintenance 修改为通过 systemd timer 而不是原来的 cron job 来执行计划任务了。系统的 systemd timer 发现有新的计划任务从来没有执行过，就在开机启动后执行它。但是 BtrFS 文件系统的一个缺点就是需要定期执行「再平衡」操作来维护（还可能有 btrfs-scrub.timer）。开机执行的还有诸如 snapper-timeline.timer、snapper-cleanup.timer、systemd-tmpfiles-clean.timer、fstrim.timer 等。这些都可能要比较长的时间。造成的现象就是好像开机进程停滞了。如果「停止」的时间比通常开机的时间长很多，就会让用户造成系统无法启动的错觉。博主当时等了一会儿，大约不到3分钟吧，就按电源键给关机了，因为平常都是不到30秒就进桌面了。而这一次这么「鲁莽」还有一个原因是，系统在几个小时前从睡眠中恢复之后完全无响应只能硬关机重启造成的惯性思维。

当时急慌之下还跑到邮件列表上去问。后来发现没问题之后大家又讨论了一下是否可以将这些任务延迟到系统启动用户登录界面显示出来之后再执行。结果是很麻烦。暂时也只能这样了。

上面提到的一些定时任务会周期执行，每周、每两周或者每个月等等，所以以后可能会经常碰到类似的情况。以后需要长点记性，稍微有耐心一点，多等等。©

本文发表于水景一页。永久链接：<http://cnzhx.net/blog/fake-boot-halt-after-updating-opensuse-tumbleweed-20180120/>。转载请保留此信息及相应链接。