设备环境:N100 V1.1.23物理机
BUG现象:每日凌晨硬盘自动唤醒(ai帮助排查了下,供参考)
出现频率:(必现)
联系方式:(18841030505)
日志文件:https://share.xzming.top:8888/s/4b78b815dacf41c683
附件过大无法上传可以通过飞牛外链分享或者百度网盘提供日志文件
<官方授权或自有硬件的用户,可直接联系客服,享一对一服务>
🐞 Bug 反馈报告:smbftpd / webdav 服务异常重启导致硬盘被频繁唤醒
一、问题概述(Issue Summary)
在系统正常空闲状态下,机械硬盘(sda)每天凌晨会被异常唤醒,即使用户未进行任何访问操作、Docker 容器位于 SSD、共享目录为静态资源(照片等)。
经排查发现,smbftpd 与 webdav 服务因 TLS 证书路径失效进入无限重启循环(Restart Storm),从而周期性访问磁盘并唤醒机械硬盘。
二、系统环境(Environment)
- 系统类型:Linux NAS 系统(trim 框架)
- 文件系统:
- 数据盘:btrfs(LVM + RAID1 + SSD cache,cache_mode = writethrough)
- Docker / 系统盘:NVMe SSD
- 机械硬盘型号:
- 相关服务:
trim_main.service
smbftpd.service
webdav.service
- systemd 版本:systemd(Restart=always)
三、问题现象(Symptoms)
- 机械硬盘在凌晨被唤醒(示例时间):
- 2026-02-27 00:59:16
- 2026-02-27 02:38:22
- 2026-03-01 02:38:00
- 2026-03-03 02:04:23
- 唤醒发生时:
- 无用户访问
- 无 Docker 任务
- 无定时任务写入数据盘
- 磁盘会在一段时间后再次休眠(可在 trim_main 日志中看到 DiskSpindown)
四、已完成的排查工作(Troubleshooting Performed)
1️⃣ 排除系统级定时任务
👉 未发现与凌晨时间点匹配的定时任务。
2️⃣ 排除文件系统 / RAID / LVM 层问题
- 未发现 resync / check / rebuild
- LVM cache 模式为
writethrough,确认不会引入写回延迟
- Docker 数据全部位于 SSD,不涉及机械盘
3️⃣ 使用 auditd 精确捕获触发源
启用 auditd 并监控数据卷:
在 2026-03-03 02:04:23 捕获到大量 systemd 服务启动 / 停止事件:
事件在数分钟内 每 5 秒重复一次。
4️⃣ 确认服务异常重启(Restart Storm)
smbftpd.service 与 webdav.service 均配置为:
systemd 日志显示重启计数已达:
5️⃣ 定位根因:TLS 证书路径失效
smbftpd 日志:
webdav 日志:
实际验证:
证书目录 整体不存在。
6️⃣ trim_main 日志佐证磁盘唤醒
在同一时间点,trim_main 记录磁盘唤醒事件:
随后在一段时间后:
五、问题结论(Root Cause)
根因确认:
smbftpd 与 webdav 服务依赖的 TLS 证书目录
/usr/trim/var/trim_connect/ssls/fnOS/1734792732/
不存在,导致服务启动失败。
由于 systemd 配置为 Restart=always,服务进入 无限重启循环(每 5 秒一次),反复访问配置、证书路径及共享目录,从而唤醒机械硬盘。
六、影响(Impact)
- 机械硬盘在空闲状态下被频繁唤醒
- 影响硬盘寿命与节能策略
- 系统无明显告警,问题隐蔽
- 用户难以通过常规方式发现根因
七、临时规避方案(Workaround)
八、改进建议(Suggestions)
- 证书缺失时禁止无限重启
- trim 主服务应校验证书完整性
- 在启动 smbftpd / webdav 前检查证书是否存在
- 若不存在应明确告警,而非进入重启风暴
- 证书路径不应硬编码时间戳目录
- 磁盘唤醒应记录触发进程
九、总结
该问题并非文件系统、RAID、缓存或 Docker 导致,而是 应用层服务异常重启引发的连锁磁盘唤醒问题。
问题定位已完成,具备明确复现路径与修复方向。