事情的起因是在逛论坛时看到一个帖子说可以通过把/var/log目录映射到/tmp下，使用内存而不是硬盘记录日志信息，减少硬盘的读写，达到使硬盘休眠的目的。想了想，我家硬盘这么多，都休眠的话，估计能省好多电费。于是在好奇之下，搜了一下相关的设置，发现除了修改日志目录以外还有很多设置会影响到硬盘休眠，于是一一照做，当时完全没考虑到这些设置有可能导致NAS崩溃…… 其中最致命的一个设置如下图： 勾选该设置并保存之后DSM界面瞬间就崩溃了，无法打开、无法重启，在公司干着急，冷汗都冒出来了。 下班赶紧回家，发现NAS已经完全无法访问了（DSM和SSH），只能硬重启，还好重启之后SSH可以进NAS了，但是已经非常卡了，感觉NAS系统应该是进了什么逻辑死锁，即崩又卡，硬重启好几次都无法解决，感觉已经彻底完蛋了…… 想想NAS装系统的复杂度，而且现在大佬的arpl驱动服务器可能早就已经下线，无法安装NAS了。就算重装成功，这几年来使用NAS所安装的软件、所改写的设置，多的无法胜数，真的要撞墙了啊！哭的声调都不知道是该用美声还是流行…… 秉着死马当活马医的心态，想了想今天最主要的修改是两个： 1、/var/log/映射到/tmp下； 2、勾选了“启用系统休眠调试模式”； 一个一个解决吧。 于是先搜索了下用户计划任务，幸运的是grep在/usr/syno/下匹配到了esynoscheduler.db文件，拷出来一看果然是sqlite数据库，里面就有今天新设置的开机映射/var/log/到/tmp下的计划任务，果断删除修复之，然而重启后并未解决DSM崩溃的问题…… 继续上路，把“系统休眠调试模式”贴到google翻译，出来结果“System sleep debug mode”，以码农的直觉，感觉这翻译完全不对，没法用这个去搜索。没办法，只能靠自己在/usr/syno/下grep相关的字段了，首先搜索“debug”，我本来还以为这么普通的关键词，至少能搜出来几百上千个命中行，没想到只有几十行而已，其中一行的命中词是“enable_hibernation_debug=yes”，非常直觉的，当时一眼就觉得这项设置有问题，“hibernation”是什么意思？google翻译了一下，是“休眠”！肯定就是它！把这一项改成no之后，保存并重启NAS，DSM成功打开，所有服务次第运行，全部启动成功！ NAS救回来了！
