更新完1.1.26以后频繁重启

支xx · 2026-4-1 22:44:24

系统版本：X86（cpu amd ryzen 3500x,内存2*8g，系统盘在一个单独ssd里，）

设备环境：物理机，局域网

系统版本号1.1.26

BUG现象：更新以后大约每隔一小时都要重启，我把系统日志都导出来发给了work buddy，分析结果如下：

飞牛OS (fnOS) 频繁重启问题 — 日志分析报告

问题概述

飞牛OS（主机名：LZHOME2）从2026年3月29日起出现极其频繁的重启问题，3月29日至4月1日共计重启60+次，严重影响系统可用性。

根因分析

根因一：CRON 定时关机任务（历史问题，已自3月29日消失）

严重程度：🟡 中（已不触发，但需确认是否彻底清除）

在 syslog.1（较早日志）中发现明确的证据：

CRON[1563953]: (root) CMD (poweroff)     @ 2026-03-24 01:00:01
CRON[1563530]: (root) CMD (poweroff)     @ 2026-03-25 01:00:01
CRON[1563043]: (root) CMD (poweroff)     @ 2026-03-26 01:00:01
CRON[1562244]: (root) CMD (poweroff)     @ 2026-03-27 01:00:01
CRON[108778]: (root) CMD (poweroff)      @ 2026-03-28 01:00:01
CRON[36405]:  (root) CMD (poweroff)      @ 2026-03-29 01:00:01

现象：每天凌晨 01:00:01，root 的 crontab 执行 poweroff，系统关机后次日约 08:16 被 BIOS/网络唤醒自动开机。

说明：这是飞牛OS的"定时开关机"功能（计划任务）。从3月29日 01:00 之后该 CRON 关机任务不再出现，说明你可能在3月28日前后取消了这个定时任务。

根因二：fn-scheduler（任务计划）应用异常导致系统循环重启（当前主因）

严重程度：🔴 严重

从3月29日起，系统出现大量无规律重启，与 fn-scheduler（任务计划）应用直接关联：

关键证据链

每次系统启动后，fn-scheduler 会被自动启动（APP_AUTO_STARTED 事件）：

2026-04-01T15:40:08 TRIMEVENT: UPDATE "app" SET "is_non_manual_stop"=true,"status"='start' WHERE app_name = 'fn-scheduler'
2026-04-01T15:41:53 TRIMEVENT: fn-scheduler APP_AUTO_STARTED

每次 fn-scheduler 启动后约20-30分钟，系统就触发 shutdown：
- 例1：15:41:53 fn-scheduler 启动 → 21:42:48 系统重启（间隔约6小时，系统中途其他原因重启过）
- 例2：21:43:40 fn-scheduler 启动 → 21:46:10 系统重启（间隔仅2.5分钟！）
- 例3：21:48:40 fn-scheduler 启动 → 22:11:10 shutdown.target 被触发
重启模式呈现"启动 → fn-scheduler 启动 → 短时间内再次重启"的循环

重启频率统计（3月29日 - 4月1日）

日期	重启次数	备注
3月29日	~18次	从凌晨1点CRON关机后开始频繁重启
3月30日	~9次	仍然频繁
3月31日	~20次	重启最为密集
4月1日	~10次	截至日志导出时间

关键日志片段（4月1日傍晚的典型循环）

# 系统启动 21:42:48 systemd[1]: Starting systemd-update-utmp.service - Record System Boot/Shutdown in UTMP 21:43:08 systemd[1]: Started trim_main.service 21:43:40 TRIMEVENT: fn-scheduler APP_AUTO_STARTED ← 任务计划被自动启动 21:46:10 systemd[1]: Starting systemd-update-utmp.service - Record System Boot/Shutdown ← 又一次重启！ # 仅运行了约3分钟就被重启了第二次尝试

21:46:10 systemd[1]: Starting systemd-update-utmp.service 21:46:27 systemd[1]: Started trim_main.service 21:48:40 TRIMEVENT: fn-scheduler APP_AUTO_STARTED ← 任务计划又被自动启动 22:11:10 systemd[44090]: Reached target shutdown.target - Shutdown ← 22分钟后触发关机

诊断结论

你的飞牛OS频繁重启有 两层原因：

第一层（历史，已消除）

**CRON 定时 poweroff**：每天凌晨1点关机，次日8点自动唤醒。这在3月29日后已不再触发。

第二层（当前，正在发生）

**fn-scheduler（任务计划）应用存在 bug：该应用在系统启动后自动运行，但其内部某个定时任务配置异常，会触发系统关机/重启。由于设置了 is_non_manual_stop=true（非手动停止），每次重启后它又被自动启动，形成重启循环**。

修复建议

立即修复（停止重启循环）

登录飞牛OS Web 管理界面
进入"应用中心" → "任务计划"（fn-scheduler）
停止该应用，并关闭"开机自启动"选项
检查任务计划中是否有"重启"或"关机"类型的计划任务，将其删除或禁用

通过 SSH 修复（如果 Web 界面无法访问）

bash****复制

# 1. 停止任务计划应用 docker stop fn-scheduler 2>/dev/null || systemctl stop fn-scheduler 2>/dev/null 2. 禁用开机自启动（通过飞牛OS命令行）进入飞牛OS的数据库，修改fn-scheduler的auto_start状态 sqlite3 /usr/trim/data/app.db "UPDATE app SET is_non_manual_stop=false WHERE app_name='fn-scheduler';" 3. 检查crontab中是否还有残留的poweroff crontab -l 如果有 poweroff 相关条目，用 crontab -e 删除

反馈给飞牛官方

这是 fn-scheduler 应用的 bug，建议去飞牛OS官方群反馈以下信息：

供反馈的关键日志

证据1：fn-scheduler 触发 APP_AUTO_STARTED 后系统重启

2026-04-01T21:43:40.223475+08:00 LZHOME2 TRIMEVENT[2838]: TRIMEVENT:{"data":{"APP_GROUP":"","APP_ID":46,"APP_NAME":"fn-scheduler","APP_USERNAME":"","DISPLAY_NAME":"任务计划","INSTALL_VOLUME_ID":0,"META_VOLUME_ID":0,"PORT_USAGE":0},"datetime":1775051020,"eventId":"APP_AUTO_STARTED","from":"trim.app-center","level":0}
2026-04-01T21:46:10.201919+08:00 LZHOME2 systemd[1]: Starting systemd-update-utmp.service - Record System Boot/Shutdown in UTMP...

↑ fn-scheduler 启动后仅 2分30秒 系统就重启了。

证据2：fn-scheduler 数据库记录被设置为非手动停止（自动重启）

2026-04-01T15:40:08.513083+08:00 LZHOME2 trim_app_center[2865]: UPDATE "app" SET "is_non_manual_stop"=true,"status"='start' WHERE app_name = 'fn-scheduler'

证据3：重启循环的完整序列（4月1日 21:42-22:11）

# === 第一次启动 ===
2026-04-01T21:42:48.944415+08:00 LZHOME2 systemd[1]: Starting systemd-update-utmp.service - Record System Boot/Shutdown in UTMP...
2026-04-01T21:43:08.095236+08:00 LZHOME2 systemd[1]: Started trim_main.service - trim main service.
2026-04-01T21:43:40.223475+08:00 LZHOME2 TRIMEVENT[2838]: TRIMEVENT: APP_AUTO_STARTED - fn-scheduler（任务计划）
=== 2分30秒后第二次重启 ===
2026-04-01T21:46:10.201919+08:00 LZHOME2 systemd[1]: Starting systemd-update-utmp.service - Record System Boot/Shutdown in UTMP...

2026-04-01T21:46:27.995705+08:00 LZHOME2 systemd[1]: Started trim_main.service - trim main service.

2026-04-01T21:48:40.297108+08:00 LZHOME2 TRIMEVENT[2827]: TRIMEVENT: APP_AUTO_STARTED - fn-scheduler（任务计划）
=== 22分钟后触发关机 ===
2026-04-01T22:11:10.207311+08:00 LZHOME2 systemd[44090]: Stopped target default.target - Main User Target.

2026-04-01T22:11:10.208091+08:00 LZHOME2 systemd[44090]: Reached target shutdown.target - Shutdown.

证据4：历史 CRON 关机任务（syslog.1 中的记录）

2026-03-24T01:00:01.793622+08:00 LZHOME2 CRON[1563953]: (root) CMD (poweroff)
2026-03-25T01:00:01.655335+08:00 LZHOME2 CRON[1563530]: (root) CMD (poweroff)
2026-03-26T01:00:01.138492+08:00 LZHOME2 CRON[1563043]: (root) CMD (poweroff)
2026-03-27T01:00:01.422937+08:00 LZHOME2 CRON[1562244]: (root) CMD (poweroff)
2026-03-28T01:00:01.268792+08:00 LZHOME2 CRON[108778]: (root) CMD (poweroff)
2026-03-29T01:00:01.965079+08:00 LZHOME2 CRON[36405]: (root) CMD (poweroff)

系统环境信息

项目	值
主机名	LZHOME2
OS	飞牛OS (fnOS) - 基于 Debian
内核特性	AMD SP5100 TCO WatchDog, ACPI Power Button
Docker	已启用 (containerd + dockerd)
UPS	Network UPS Tools (nut-monitor) 已配置
已安装应用	迅雷、qBittorrent、百度网盘、FlyPic、EasyTier-Web、虚拟机、文件快照、HomeAssistant、相册、影视、安全中心、iSCSI、Office预览等
日志时间范围	2026-03-24 ~ 2026-04-01 22:17

出现频率：必现

联系方式：（群：飞牛私有云fnos274,昵称：支）

SDK · 2026-4-3 14:40:35

我的飞牛系统也一直莫名重启，找不到原因

支xx · 2026-4-7 19:49:40

SDK 发表于 2026-4-3 14:40
我的飞牛系统也一直莫名重启，找不到原因

我用workbuddy排查了半天，说是跟硬盘休眠有关系，但是关了以后也只是间隔时间长了一点，从一个小时变到了五六个小时

在哪跌倒こ就在 · 2026-4-8 14:31:01

顶起来，我也是一样的问题

支xx · 2026-4-10 22:25:56

用workbuddy排查了几天，目前看应该是好了，应该是扩展卡休眠导致的，以下是我用workbuddy总结出的结论：

飞牛NAS随机重启排查记录：ASM1061 SATA扩展卡导致的AHCI控制器失联

问题描述

升级飞牛后，NAS出现频繁随机重启，每天少则两三次，多则十几次。涉及的硬盘（ST8000VN0022 和 ST4000VN008）SMART参数全部正常，不是硬盘本身的问题。

排查过程中发现，每次重启前2-3分钟都有"推出硬盘"的事件记录，容易误判为硬盘故障。实际上真正的原因是SATA扩展卡的AHCI控制器在运行中突然失联。

第一步：开启持久化日志

飞牛默认重启后日志会丢失，必须先开启持久化，否则每次重启都看不到崩溃原因。

bash****复制

sudo mkdir -p /var/log/journal/
sudo systemd-tmpfiles --create --prefix /var/log/journal

开启后，可以用 sudo journalctl --list-boots 查看历史启动记录。

第二步：从日志中定位问题

开启持久化日志后，等下一次重启发生，然后查看上一次启动的崩溃日志：

bash****复制

sudo journalctl -b -1 --no-pager | grep -iE "ahci|ata[0-9]|SError|controller|frozen|unavailable" | tail -30

如何判断问题

正常情况下，这条命令应该输出很少甚至没有内容。如果看到以下关键字，说明有问题：

关键字	含义
`AHCI controller unavailable!`	AHCI控制器完全失联，这是最严重的问题
`exception Emask 0x52 ... frozen`	ATA端口冻结
`failed command: FLUSH CACHE EXT`	向硬盘发送刷缓存命令失败
`SATA link down (SStatus FFFFFFFF)`	SATA链路断开
`hard resetting link`	正在尝试重置链路（通常已来不及）
`SError: { ... }`	SATA链路错误，内容越长越严重

我遇到的典型崩溃日志

ata9.00: exception Emask 0x52 SAct 0x0 SErr 0xffffffff action 0xe frozen
ata9: SError: { RecovData RecovComm UnrecovData Persist Proto HostInt PHYRdyChg PHYInt CommWake 10B8B Dispar BadCRC Handshk LinkSeq TrStaTrns UnrecFIS DevExch }
ata9.00: failed command: FLUSH CACHE EXT
ahci 0000:07:00.0: AHCI controller unavailable!
ata10: failed to resume link (SControl FFFFFFFF)
ata9: SATA link down (SStatus FFFFFFFF SControl FFFFFFFF)

关键信息是 0000:07:00.0，这是出问题的设备地址。

第三步：确认问题设备

用 lspci 查看这个地址对应的是什么硬件：

bash****复制

lspci -v -s 0000:07:00.0

输出：

07:00.0 IDE interface: ASMedia Technology Inc. ASM1061 SATA IDE Controller (rev 01)
        Subsystem: ASMedia Technology Inc. ASM1061 Serial SATA Controller
        Kernel driver in use: ahci
        Kernel modules: ahci, ata_generic

确认了：这是一张 ASMedia ASM1061 SATA 扩展卡，上面接了两块盘（ata9 和 ata10），控制器在运行中突然掉线，导致两块盘同时丢失，系统崩溃重启。

问题原因

飞牛升级后内核更新到 6.12.18，新内核的 PCIe 电源管理（ASPM）行为发生了变化。ASM1061 扩展卡在运行中被 PCIe 省电策略影响，控制器突然失联。升级前旧内核没有这个问题，所以之前用得很好。

不是硬盘坏了，不是扩展卡坏了，是内核对 PCIe 设备的电源管理兼容性问题。

解决方案

通过修改 GRUB 启动参数，禁用 PCIe 电源管理来防止扩展卡掉线。

操作步骤

1. 编辑 GRUB 配置文件

bash****复制

sudo nano /etc/default/grub

2. 修改以下两行

找到这两行（内容可能略有不同，按实际情况修改）：

GRUB_CMDLINE_LINUX_DEFAULT="quiet i915.force_probe=7d55"
GRUB_CMDLINE_LINUX="modprobe.blacklist=pcspkr pcie_aspm=off"

改成：

GRUB_CMDLINE_LINUX_DEFAULT="quiet i915.force_probe=7d55 pcie_aspm=force pcie_port_pm=off"
GRUB_CMDLINE_LINUX="modprobe.blacklist=pcspkr pcie_aspm=off pci=nommconf"

3. 保存退出

Ctrl+O → 回车 → Ctrl+X

4. 更新 GRUB 并重启

bash****复制

sudo update-grub
sudo reboot

修改说明

参数	作用
`pcie_aspm=off`	禁用 PCIe 链路电源管理（可能已有）
`pcie_aspm=force`	强制 ASPM 为最激进模式，避免链路状态协商出错
`pcie_port_pm=off`	禁用 PCIe 端口电源管理，比 pcie_aspm=off 更彻底
`pci=nommconf`	使用传统 IO 方式访问 PCI 配置空间，兼容性更好

副作用是扩展卡不会自动省电，但对一张双口 SATA 卡来说功耗差异不到 1W，可以忽略。

验证方法

重启后执行：

bash****复制

# 确认参数生效
cat /proc/cmdline

# 确认扩展卡正常
lspci -k -s 0000:07:00.0

# 确认没有 AHCI 错误
sudo dmesg | grep -iE "ahci|SError|unavailable|frozen"

正常情况下最后一步应该没有输出（或只有初始化信息，没有 error/unavailable/frozen）。

其他可能遇到的情况

如果你的 lspci 显示的不是 ASM1061 而是其他型号的 SATA 卡或 HBA 卡，排查思路一样：看 journalctl 里对应的 PCIe 地址的 AHCI 错误
如果修改 GRUB 后仍然重启，且日志显示同一个控制器失联，可能需要考虑更换 SATA 扩展卡
如果你的盘接在主板自带 SATA 口上，那问题可能是主板本身的 SATA 控制器兼容性，GRUB 参数仍然值得尝试

环境

飞牛NAS，内核 6.12.18-trim
问题硬件：ASMedia ASM1061 SATA 扩展卡（PCIe 转双口 SATA）
涉及的盘：希捷酷狼 ST8000VN0022、ST4000VN008（SMART正常）

希望对遇到同样问题的朋友有帮助。

支xx · 2026-4-10 22:31:42

在哪跌倒こ就在发表于 2026-4-8 14:31
顶起来，我也是一样的问题

我的应该弄好了，用workbuddy分析日志做的，不过wb有时候会瞎说，他会自己理解值，我后来让他在ssh里建立日志分析那个日志他才分析出来，飞牛自带的日志少很多东西。这个思路你可以参考一下。

直角三角熊 · 2026-4-20 09:51:19

一样问题，频繁重启

		自动登录	找回密码
密码			立即注册

更新完1.1.26以后频繁重启

飞牛OS (fnOS) 频繁重启问题 — 日志分析报告

问题概述

根因分析

根因一：CRON 定时关机任务（历史问题，已自3月29日消失）

根因二：fn-scheduler（任务计划）应用异常导致系统循环重启（当前主因）

关键证据链

重启频率统计（3月29日 - 4月1日）

关键日志片段（4月1日傍晚的典型循环）

第二次尝试

诊断结论

第一层（历史，已消除）

第二层（当前，正在发生）

修复建议

立即修复（停止重启循环）

通过 SSH 修复（如果 Web 界面无法访问）

2. 禁用开机自启动（通过飞牛OS命令行）

进入飞牛OS的数据库，修改fn-scheduler的auto_start状态

3. 检查crontab中是否还有残留的poweroff

如果有 poweroff 相关条目，用 crontab -e 删除

反馈给飞牛官方

供反馈的关键日志

证据1：fn-scheduler 触发 APP_AUTO_STARTED 后系统重启

证据2：fn-scheduler 数据库记录被设置为非手动停止（自动重启）

证据3：重启循环的完整序列（4月1日 21:42-22:11）

=== 2分30秒后第二次重启 ===

=== 22分钟后触发关机 ===

证据4：历史 CRON 关机任务（syslog.1 中的记录）

系统环境信息

本帖子中包含更多资源

点评

点评

飞牛NAS随机重启排查记录：ASM1061 SATA扩展卡导致的AHCI控制器失联

问题描述

第一步：开启持久化日志

第二步：从日志中定位问题

如何判断问题

我遇到的典型崩溃日志

第三步：确认问题设备

问题原因

解决方案

操作步骤

修改说明

验证方法

其他可能遇到的情况

环境

如果有 `poweroff` 相关条目，用 crontab -e 删除