Я работаю 12.04 на домашнем сервере / HTPC, и у меня есть несколько накопителей, которые вращаются, используя значения, установленные в /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
? Как я могу понять, как это называется?
Я тоже некоторое время боролся с этой проблемой, попробовав одитинг, упомянутое правило удисков и т. Д. Но, наконец, именно blktrace
и blkparse
дали мне последний намек на проблему: мои спящие диски были доступ по dumpe2fs
при входе в систему через ssh.
Очевидно, что следующий скрипт был нарушителем, сканируя все диски, чтобы показать, какие диски будут проверены на ошибки при следующей перезагрузке вашего motd при входе в систему.
/ usr / lib / update-notifier / update-motd-fsck-at-reboot
blockquote>Сценарий выполняется только один раз в час максимум, поэтому это объясняет, почему он не был не происходит последовательно. Смотрите строки 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
неоценимое значение для диагностики проблемы.