web-dev-qa-db-ja.com

SSHログインがスピンダウンストレージドライブを起動

12.04をホ​​ームサーバー/ HTPCで実行しており、/etc/hdparm.confに設定された値を使用してスピンダウンするストレージドライブがいくつかあります。

時々、sshを介してログインすると、一部またはすべてのドライブがウェイクアップします。私は this の投稿で推奨されている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自体によってウェイクアップされていますか？それが何と呼ばれているのかをどうやって理解できますか？

sshpower-managementdriveudisks
2
absqua

私はまた、この正確な問題にしばらく取り組んでおり、監査や前述のudisksルールなどを試しました。しかし、最後にblktraceとblkparseが問題の最終的なヒントを与えてくれました。スリープ中のディスクは、sshログイン時にdumpe2fsによってアクセスされました。

明らかに、次のスクリプトは違反者であり、すべてのドライブをスキャンして、ログイン時のmotdの次の再起動時にエラーがチェックされるドライブを表示します。

/ usr/lib/update-notifier/update-motd-fsck-at-reboot

スクリプトは最大1時間に1回しか実行されないため、これが一貫して発生しなかった理由を説明しています。 21〜24行目を参照してください。

if [ $(($stampt + 3600)) -lt $now ] || [ $stampt -gt $now ]; then
    #echo $stampt $now need update
        NEEDS_FSCK_CHECK=yes
fi

変数の割り当てを:（何もしない）に置き換えることで、システムの自動チェックを無効にすることにしました。また、3600秒の最小時差を1日や1週間などに増やすこともできます。しかし、ディスクがすべてとにかく起きている深夜のメンテナンス中に--forceを使用してスクリプトを実行することをお勧めします。このスクリプトは情報提供のみを目的としているため、この情報に関心がない場合は、return 0に置き換えるだけで安全です。

これが同じまたは同様の問題を抱えている人を助けることを願っています。それがあなたのシステムの別の犯人であったとしても、私はblktraceとblkparseが問題の診断に非常に貴重であるとわかりました。

4
jvanhie