SSH-вход активирует дисковые накопители

Я работаю 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? Как я могу понять, как это называется?

1
задан 17 April 2013 в 07:04

1 ответ

Я тоже некоторое время боролся с этой проблемой, попробовав одитинг, упомянутое правило удисков и т. Д. Но, наконец, именно 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 неоценимое значение для диагностики проблемы.

0
ответ дан 17 April 2013 в 07:04

Другие вопросы по тегам:

Похожие вопросы: