关于systemd服务被cron_for_fix.service卡住的问题

好想打kuo碎

以下是我在更新系统后发现的问题和解决方法，包括一些猜测，具体原因如何未知，技术同学看到后麻烦确认我下面的内容是否正确。

平时我比较喜欢ssh进入飞牛手搓一些nftables、wireguard服务，以保证安全和异地组网，而这些手搓的服务我一般都喜欢放在multi-user.target后运行启动，因为这时候的虚拟带宽等设备都已经完全启动了，nftables配置中写了iifname xxx就可以正常启动了。

但在飞牛1.1.18版本更新后，我发现了一个systemd服务上的问题，我发现更新了1.1.18版本后手搓的nftables、wireguard服务居然无法正常启动了，深入研究发现是multi-user.target这个组件被卡住了，而我手搓的服务启动依赖于multi-user.target。

使用systemctl list-**s查看后发现很多服务都没有完成启动，其中service@.service和nftables.service是我手动调整的，其余的服务中除了cron_for_fix.service外都是系统自带的服务，那么问题可能出现在cron_for_fix.service

# systemctl list-**s

** UNIT                                 TYPE  STATE
236 service@wg1.service                  start waiting
194 cron_for_fix.service                 start running
1   graphical.target                     start waiting
242 nftables.service                     start waiting
2   multi-user.target                    start waiting
252 service@wg0.service                  start waiting
228 system_shutdown.service              start waiting
186 systemd-update-utmp-runlevel.service start waiting

查看cron_for_fix.service的systemd配置文件和启动脚本

# cat /etc/systemd/system/cron_for_fix.service

[Unit]
Description=Run custom script After trim_main
After=trim_main.service

[Service]
Type=oneshot
ExecStart=/usr/trim/bin/cron_for_fix.sh
TimeoutStopSec=3
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

root@NAS-Private:~# cat /usr/trim/bin/cron_for_fix.sh
#!/bin/bash

while true; do
    /usr/trim/bin/liveupdate -Hu
    sleep 5h
done

到这里发现了问题所在，这里可以看到crom_for_fix.service会在multi-user.target前被启动，具体来说，它每5小时运行一次 /usr/trim/bin/liveupdate -Hu 命令，liveupdate 大概是飞牛的系统更新工具，用于检查、下载和应用系统更新或修复。

但问题是，这个循环脚本的systemd得类型设置得是oneshot，systemd服务会等待oneshot类型的服务关闭然后进行后续的服务启动，但这是一个循环脚本，就导致systemd服务一直在等待crom_for_fix.service服务关闭，导致crom_for_fix.service后续的所有服务都被挂起等待启动。

修复方式也很简单，只需要将oneshot类型改为simple类型，再重启系统守护进程即可，这样systemd服务在启动crom_for_fix.service时就不会等待它关闭，而是放在后台任由它循环执行

[Service]
Type=simple

systemctl daemon-reload

我猜测 cron_for_fix很可能是一中安全机制，为了“长期监控”更新状态，官方可能添加这个服务作为“修复机制”，目的是定期强制检查更新，以应用安全补丁，防止类似的干预反复发生。但是添加的时候不确定原因是什么使用的一次性类型导致后续systemd服务均被卡住

飞牛技术同学

已收到反馈 我转给负责的同事看看