O login SSH desperta unidades de armazenamento desativadas

Question

Estou executando o 12.04 em um servidor doméstico / HTPC e tenho várias unidades de armazenamento que desaceleram usando valores definidos em /etc/hdparm.conf .

Às vezes, , o login via ssh faz com que algumas ou todas as unidades sejam ativadas. Eu defini a regra udisks recomendada em esta postagem, e a mudança foi de todo o tempo para apenas uma parte do tempo.

Eu configurei as regras de auditoria, auditctl -w /dev/sde -p rwa -k e , por exemplo, para tentar ver o que estava acontecendo com elas. Verificando os resultados da auditoria com ausearch , vejo entradas como esta quando eu ssh in:

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

Então, minhas unidades estão sendo despertadas por hdparm ? Como posso descobrir o que está chamando?

    

Answer 1

Eu também estava lutando com esse problema por um tempo, tendo tentado auditorias, a regra dos udisks mencionada etc. Mas finalmente foi blktrace e blkparse que me deu a última dica do problema: meus discos de dormir eram acessado por dumpe2fs no login do ssh.

Aparentemente, o script a seguir foi o ofensor, examinando todas as unidades para exibir quais unidades serão verificadas quanto a erros na próxima reinicialização do seu motor durante o login.

  

/ usr / lib / update-notifier / update-motd-fsck-à-reinicialização

O script só é executado uma vez a cada hora, o que explica por que isso não estava acontecendo de forma consistente. Veja as linhas 21-24:

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

Eu decidi desativar a verificação automática no meu sistema, substituindo a atribuição de variável para : (não fazer nada). Você também pode aumentar a diferença de tempo mínimo de 3600 segundos para algo como um dia ou uma semana. Mas achei preferível executar o script com --force durante a manutenção da meia-noite, quando todos os meus discos estão ativados de qualquer maneira. Como esse script é puramente informativo, deve ser seguro substituí-lo apenas por return 0 se você não estiver interessado nessas informações.

Espero que isso ajude alguém a ter o mesmo problema ou um problema semelhante. Mesmo que seja outro culpado em seu sistema, achei blktrace e blkparse inestimáveis para diagnosticar o problema.