abs*_*qua 2 ssh power-management udisks drive
我在家庭服务器/HTPC 上运行 12.04，并且有几个存储驱动器使用/etc/hdparm.conf.
有时，通过登录ssh会导致部分或全部驱动器唤醒。我设置了这篇文章中udisks推荐的规则，并且旋转从一直到只是一些时间。
auditctl -w /dev/sde -p rwa -k e例如，我设置了审计规则，试图查看是什么唤醒了他们。使用 来检查审计结果ausearch，当我ssh进入时看到这样的条目：
type=PATH msg=audit(04/16/2013 18:16:40.109:502) : item=0 name=/dev/sde inode=3010 dev=00:05 mode=block,660 ouid=root ogid=disk rdev=08:40
type=CWD msg=audit(04/16/2013 18:16:40.109:502) : cwd=/home/absqua
type=SYSCALL msg=audit(04/16/2013 18:16:40.109:502) : arch=x86_64 syscall=open success=yes exit=3 a0=7fffcd697998 a1=800 a2=0 a3=0 items=1 ppid=14054 pid=14055 auid=root uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts0 ses=408 comm=hdparm exe=/sbin/hdparm key=e
那么，我的驱动器正在被hdparm自己唤醒？我怎样才能弄清楚它叫什么？
小智 5
我也用了一段时间这个确切问题挣扎，尝试过审计，提到udisks规则等，但最后却是blktrace和blkparse这给了我这个问题的最终提示：我睡觉的磁盘被访问dumpe2fs的ssh登录。
显然，以下脚本是违规者，它扫描所有驱动器以显示在下次登录时在 motd 上重新启动时将检查哪些驱动器是否有错误。
/usr/lib/update-notifier/update-motd-fsck-at-reboot
该脚本最多每小时仅执行一次，因此这解释了为什么它没有始终如一地发生。见第 21-24 行：
if [ $(($stampt + 3600)) -lt $now ] || [ $stampt -gt $now ]; then
#echo $stampt $now need update
NEEDS_FSCK_CHECK=yes
fi
我决定通过将变量分配替换为:（什么都不做）来禁用系统上的自动检查。您还可以将3600秒的最小时差增加到一天或一周之类的时间。但是我发现最好--force在午夜维护期间运行脚本，此时我的所有磁盘都处于唤醒状态。由于此脚本纯粹是信息性的，return 0如果您对此信息不感兴趣，只需将其替换为 应该是安全的。
我希望这可以帮助任何有相同或类似问题的人。即使这是你的系统上的另一个罪魁祸首，我发现blktrace和blkparse宝贵的诊断问题。