黑群晖之硬盘休眠（怪物空闲管理器）

本文永久链接：https://www.xy1413.com/p/syno_hdd_hibernation/

背景

之前做AIO家庭服务器时，做了一个黑群晖虚拟机，把其当作家庭主要NAS使用，同时将原来古董级的DS216Play作为备份机使用。

本以为这一切就完了，慢慢使用NAS就是了，但一次偶然机会看到CMS，然后就安装了。在一个软件里面管理两台群晖NAS真的很方便。

但是，某天我发现DS216Play在休眠状态，打开DSM网址居然还能正常连接。于是我查看了两台群晖的日志文件，发现DS216Play有'Internal disks woke up from hibernation.'的记录，而黑群晖却没有。我还特意去摸了摸两台NAS的硬盘，DS216Play凉凉的，而黑群晖居然有点烫手，打开DSM一看，硬盘温度53，而DS216Play只有30不到。

好吧，问题就来了，作为一台7x24小时运行的主机，硬盘休眠真的很重要，能节省不少能量，减少二氧化碳的排放。另外硬盘休眠了，温度自然也就降下来了，硬盘的寿命也会长一点。

群晖洗白

之前做好了黑群晖洗白，虽然只是半洗白，但完全够用，而且洗白操作应该不会影响硬盘休眠，唯一可能的关联就是网络唤醒（WOL）与硬盘休眠之间可能有一定的联系。检查一下总没什么错。

synoboot/grub.cfg

sudo -i mkdir -p /tmp/boot cd /dev # 一定要进入这里，然后使用相对路径挂载，不然报错。见了了 mount -t vfat synoboot1 /tmp/boot vim /tmp/boot/boot/grub/grub.cfg

修改‘sn=’/‘mac1=’/‘mac2=’后面的值
如果还未安装，可直接用DiskGenius修改synoboot.img/EFI/grub/grub.cfg

好吧，肯定会有人问这个，算号器。不要问我原始SN去哪找，这个都找不到就不要玩黑群晖了。

虚拟机设置

ESXi - 群晖虚拟机 - 编辑

网络适配器1 - E1000e - 手动 - 填写mac1对应的MAC地址

网络适配器2 - E1000e - 手动 - 填写mac2对应的MAC地址。如果不需要第二网卡，可以将‘打开电源时连接’取消掉。

验证与测试

查看内核启动参数

ssh登陆群晖并运行cat /proc/cmdline，检查sn/mac1/mac2

查看SN

群晖 - 主菜单 - 控制面板 - 信息中心 - 常规 - 硬件 - 产品序列号

查看MAC

ssh登陆群晖并运行ifconfig，检查MAC地址

登陆

群晖 - 主菜单 - 控制面板 - synology帐户 - 登陆或注册Synology帐户。

关于QuickConnect，网上有些说法，说一定要使用群晖全球注册网站，我亲身试了一下，结果没卵用物。在中国地区使用QuickConnect就要验证手机，验证手机就要帐号转移到中国区。我还特意将synology.com/synology.cn两个域名定向到香港的服务器，一样没卵用。好吧，直接放弃，半白算了。

硬盘休眠调试

群晖 - 主菜单 - 控制面板 - 硬件与电源 - 硬盘休眠 - 启动进阶硬盘休眠

时间调到最小，比如10分钟，方便调试。
启动硬盘休眠日志

方法一

群晖 - 主菜单 - 技术支持服务 - 系统日志工具 - 启用系统休眠调试模式 - 无法休眠/经常唤醒 - 应用

tail -f /var/log/hibernationFull.log # 输出 [ 4240.832392] ppid:16081(postgres), pid:16203(postgres), WRITE block 10693632 on dm-10 (32 sectors)

关注======Idle 44 seconds======这行前面的内容，逐步解决问题

通过Mon May 8 16:16:19 CST 2023定位时间区间

方法二

sudo -i sysctl vm.block_dump=1 dmesg -Tw | grep -e dirtied # 输出 [Mon May 8 15:19:46 2023] ppid:1(systemd), pid:18525(_______________), dirtied subvolume 256 inode 955288 (cmstask_db.sqlite-wal) on dm-10 # 调试完成后关闭block_dump sysctl vm.block_dump=0分析问题

退出DSM并关掉网页，关掉SMB/iSCSI/http等连接，等待10-15分钟，然后开始下载分析log。这个过程可能要进行很多次，不断的分析和查找影响硬盘休眠的原因。

下载log并开始分析

scp iSynoNAS.local:/var/log/hibernationFull.log ./ vim hibernationFull.log通过开始和结束时间定位有效log

dgg --> 删除当前行到文件开头的内容 -- 定位有效log的开始位置 dG --> 删除当前行到文件尾的内容 -- 定位有效log的结束位置过滤已经分析过的和不需要的行

:g/pattern/d --> 删除匹配的行 -- 删除分析过的和忽略的行 :g!/pattern/d --> 删除不匹配的行 -- 分析log中某个程序的周期性规律通过pid查找所运行的程序、参数、用途等

ps aux | grep -w 16081 postgres 16081 0.0 1.6 615544 64588 ? Ss 14:31 0:00 /usr/bin/postgres -D /var/services/pgsql postgres --help # 帮助信息中一般都会有程序的功能说明可疑项分析

由于开启了调试模式，会有很多log需要写到硬盘上，syno_hibernatio/synologrotated/syslog-ng相关的条目均可忽略。
tmpfs相关操作都是在内存中，也不会影响我们的硬盘休眠。
kthreadd相关内容应该是用户态程序触发的操作，直接忽略即可。
剩下的就是可疑条目，而且我们需要重点关注持续性或周期性输出的条目。

# CMS 的数据库？ [ 6337.272857] ppid:16081(postgres), pid:16201(postgres), WRITE block 10697760 on dm-10 (32 sectors) # Central Management System [ 6337.750548] ppid:1(systemd), pid:24047(_______________), dirtied subvolume 256 inode 25977 (?) on dm-9 # 找不到pid，应该是运行结束后退出的shell脚本 [ 6340.116387] ppid:1(systemd), pid:5510(sh), WRITE block 776104 on md0 (8 sectors) # 检查计划任务中是否有周期性脚本即可 [ 6364.596662] ppid:1(systemd), pid:13122(synocrond), dirtied inode 38541 (synocrond-execute.log) on md0 # 调试相关内容，直接忽略 [ 6346.774178] ppid:1(systemd), pid:7053(syno_hibernatio), dirtied inode 24563 (hibernation.log) on md0 [ 6346.774830] ppid:1(systemd), pid:7053(syno_hibernatio), dirtied inode 11644 (hibernationFull.log) on md0 # Cloud Sync, 只在测试开始出现一两次 [ 9142.353722] ppid:1(systemd), pid:9996(SYNO.CloudSync_), dirtied subvolume 256 inode 24696 (config.sqlite-wal) on dm-9 # [ 9158.884294] ppid:9474(synoscgi), pid:10158(SYNO.Core.Syslo), dirtied inode 25890 (.SYNOACCOUNTDB-shm) on md0解决问题与确认

对于找到的有问题的服务或套件，我们先可以采用停止服务或卸载套件等操作，再等待10-15分钟，再次分析，如此反复，直到所有可疑项都已经解决。

目前本人的群晖NAS就发现如下问题

Central Management System - 本来是为了管理多个NAS方便，但得不偿失，直接卸载吧

最后，我们还要关闭所有开启的调试模式，然后再次等待10-15分钟，进日志中心，如果能够找到‘Internal disks woke up from hibernation.’相关内容，这说明硬盘已经正常休眠。如果这条内容出现得过于频繁，则说明有程序在不断的唤醒硬盘，这时需要做两方面的考虑：

把硬盘休眠时间设置在一个合理的值
对影响硬盘休眠的程序做出调整

另外，我有一点建议：我们在使用群晖的过程中，往往直接开启或关闭一个服务就Ok，但实际上控制面板中很多功能和服务都有log开关，我们在开启一个功能和服务最好连其log一并开启。

结束语

很久没有认真分析过log了，定位问题的过程还是挺有乐趣的，特别是这种中间有等待时间的问题，可以喝喝咖啡、抽抽烟，整理一下自己的思路，同时将过程完整的记录下来。这大概就是程序猿的乐趣吧！！！

另外，在定位问题的过程中，我发现黑群晖的引导文件似乎一直在处理S.M.A.R.T.相关内容，这个对cpu休眠是否有影响？下次再分析吧

[ 9867.856927] <redpill/smart_shim.c:646> Got SMART *command* - looking for feature=0xd0 [ 9867.857082] <redpill/smart_shim.c:390> Generating fake SMART values2023-05-20

之前调试完的的群晖，放置一夜结果仍然没有找到‘Internal disks woke up from hibernation.’，但又实在找不到其他问题，甚至关掉的所有服务都无法休眠，于是怀疑是引导文件的问题。

所以自己编译了一个群晖引导文件，然后尝试把所有日志文件写入内存（群晖的日志文件真的有点多），结果发现了新的问题。

首先，我们来看看哪些日志文件被更新了：

ll /var/log/ | grep "May 20 01:31"

逐个看看这些日志文件都写了什么内容

tail -f /var/log/messages # 一直在循环的打印以下内容，每3秒一次，Fuck... 2023-05-20T01:30:21 08:00 iSynoNAS coredump[17101]: Process synofoto-bin-ch[17099](/volume2/@appstore/SynologyPhotos/usr/bin/synofoto-bin-check-user-group) dumped core on signal [6]. Core file [/volume1/@synofoto-bin-ch.synology_broadwell_3617xs.42962.core.gz]. Cmdline [/var/packages/SynologyPhotos/target/usr/bin/synofoto-bin-check-user-group ] 2023-05-20T01:30:21 08:00 iSynoNAS coredump[17101]: Core file [/volume1/@synofoto-bin-ch.synology_broadwell_3617xs.42962.core.gz] size [436841]

从名字synofoto-bin-check-user-group来看，应该是相册引起的权限问题，那就看看

好吧，这个权限有点出乎我的意料。但这不是当前的重点，先暂时禁用‘Synology Photos’这个套件，继续分析日志问题。

目前来看就剩下‘synolog’这一项了，但这是个目录，里面文件有点多。继续查看发现，里面文件并没有改变，只是文件夹的属性更新了。这说明有程序在一直访问这个目录。

目前找不到‘synolog’的主人，线索好像断了！！！

没关系，我们再次开启硬盘休眠调试，这次我们注意到一个可疑的条目（之前被忽略了）

[72361.957201] ppid:1(systemd), pid:14470(vmtoolsd), dirtied inode 17232 (vmsvc.sc-open-vm-tools.log) on dm-4

暂时不处理，先禁用‘VMware Tools’，退出DSM，等待10-15分。

普天同庆，我们终于看到久违的‘Internal disks woke up from hibernation.’。

接下来，我们只需要处理好‘Synology Photos’和‘VMware Tools’这两个套件的问题。

Synology Photos的问题好解决，直接用chmod修改一下。

VMware Tools：

安装新版本，这是我目前能找到最新的版本了。

又是普天同庆？怎么可能那么容易。日志文件是不见了，但还是无法休眠，算了吧，暂时先卸载吧。

==> 由于ESXi 群晖是本人将来长时间采用的方案，后面我将研究一下这个Tools。

==> 在查问题过程中，发现自己MAC地址填错了，而且SN也处于失效状态，也不知道有没有影响，都修正了一下。

2023-05-21

继续昨天的任务。

虽然现在我们的硬盘已经可以休眠，但为了避免硬盘被频繁唤醒，我们仍然要将整个日志写入内存中。为了观察这点，我们特意将群晖放置一整晚，今早通过查看日志发现，果然硬盘一进休眠就被唤醒。这应该是网上所说的由于虚拟机缺少硬盘指示灯导致scemd写日志的问题。

cat /var/log/scemd.log 2023-05-21T06:20:15 08:00 iSynoNAS scemd[13488]: event_disk_hibernation_handler.c:47 The internal disks wake up, hibernate from [May 21 06:20:03] 2023-05-21T06:20:18 08:00 iSynoNAS scemd[13488]: led.c:334 Enable power & phy LED

整晚都是这样，硬盘只能休眠几秒钟就被唤醒。好吧，放终极大招，将tmpfs挂载到'/var/log'，将所有日志写到内存中。

=> '/etc/fstab'会在开机时被‘/usr/syno/cfgen/s00_synocheckfstab’重置。如果删除或重命名这个文件，开机提示存储空间损毁。真把我吓一跳，硬盘上有不少重要东西呢。

=> 修改'/etc.default/fstab'无效。真不知道这个文件是干嘛用的。

=> 如果使用计划任务挂载tmpfs，所有套件提示损坏。大概原因是挂载'/var/log'时，已经有日志文件被打开，这时候挂载tmpfs导致之前打开的句柄无法操作。这也看得出，重定向日志文件到内存中有多重要。

=> 看来只能从syslog-ng入手了。

修改‘syslog-ng’的配置文件 -- deprecated - 直接跳下一节

sed -i 's%/var/log/%/tmp/log/%g' /etc.defaults/syslog-ng/patterndb.d/*.conf /usr/lib*/systemd/system/syslog-ng.service /usr/syno/lib/systemd/scripts/syslog-ng.sh # 同时修改logrotate sed -i 's%/var/log/%/tmp/log/%g' /etc.defaults/logrotate.d/*

大部分日志文件都已经定向到'/tmp/log'，还有部分模块和套件的日志没有修改。继续折腾

# 修改第二位置的日志配置文件 sed -i 's%/var/log/%/tmp/log/%g' /usr/local/etc/syslog-ng/patterndb.d/*.conf /usr/local/etc/logrotate.d/* # 修改第三位置的日志配置文件 # 这些位置的配置文件不修改，则第二位置的对应文件会恢复成默认 sed -i 's%/var/log/%/tmp/log/%g' /usr/local/packages/@appstore/*/etc/syslog-ng/patterndb.d/*.conf /usr/local/packages/@appstore/*/etc/logrotate.d/*

套件的日志文件不太好修改，有些套件即写'/var/log/'目录，也写'/var/packages/*/var/log/'目录，只能手动修改

# smbService sed -i 's%/var/log/samba/%/tmp/log/samba/%g' /usr/local/etc/logrotate.d/SMBService /usr/local/packages/@appstore/SMBService/resource/syslog-config/SMBService.logrotate

==> 把日志定向到内存，似乎启动过程时间更长了，为什么？

==> '/var/log/synolog/'这个不太好修改，很多模块都使用这个目录

添加systemd服务var-log.mount

修改‘syslog-ng’的配置文件时，突然想起来群晖也是使用systemd，既然这样就可以使用mount服务挂载‘/var/log’

cp /usr/lib/systemd/system/{tmp.mount,var-log.mount} vim /usr/lib/systemd/system/var-log.mount # 修改'/tmp'字段为'/var/log' ln -svf ../var-log.mount /usr/lib/systemd/system/local-fs.target.wants/ # 重启 reboot # 确认 systemctl status var-log.mount # 查看服务是否启动 mount | grep "/var/log" # 查看目录是否挂载正确

== update 2023-05-25 增加 var-lib-diskutil.mount

最后，恢复一下之前修改过的‘syslog-ng’配置文件

sed -i 's%/tmp/log/%/var/log/%g' /etc.defaults/syslog-ng/patterndb.d/*.conf /usr/lib*/systemd/system/syslog-ng.service /usr/syno/lib/systemd/scripts/syslog-ng.sh /etc.defaults/logrotate.d/* /usr/local/etc/syslog-ng/patterndb.d/*.conf /usr/local/etc/logrotate.d/* /usr/local/packages/@appstore/*/etc/syslog-ng/patterndb.d/*.conf /usr/local/packages/@appstore/*/etc/logrotate.d/* /usr/local/etc/logrotate.d/SMBService /usr/local/packages/@appstore/SMBService/resource/syslog-config/SMBService.logrotate

真的最后了，再放置一晚，明天看结果吧。

2023-05-28

/usr/syno/plugin/volume/create/SynologVolumeCreate.sh将数据库移到/volume1然后创建链接，为什么？

VMware Tools

这个套件一直在打印一条日志：

tail -f /volume*/@appstore/open-vm-tools*/var/log/vmsvc.sc-open-vm-tools.log [vmsvc] [19658] SimpleSock: Couldn't get VMCI socket family info.

参考这里，但我们找不到vmw_vmci和vmci这两个内核模块。==> 具体错误我们暂时无法解决。

但由于我们已经实现tmpfs@/var/log/，可以把这个套件的日志文件也定向到/var/log/，不用担心唤醒硬盘。

sed -i 's%/volume.*/@appstore/open-vm-tools.*/var/log/%/var/log/%g' /volume*/@appstore/open-vm-tools*/etc/vmware-tools/tools.conf rm -rf /volume*/@appstore/open-vm-tools*/var/log/*SMB Service

这个有点意外，没有数据传输的情况下，大概每小时读写一次/var/cache/samba和smbpasswd。

查看群晖官方文档发现：