como posso diagnosticar um dispositivo de invasão de software linux “congelado”?

5

Eu tenho um servidor executando o Linux 3.2.12 i686 de 32 bits com 13 unidades: 1 unidade de inicialização e 3 dispositivos raid5 de 4 unidades cada.

/ proc / mdstat mostra

Personalities : [raid1] [raid10] [raid6] [raid5] [raid4] 
md2 : active raid5 sdd1[3] sdc1[2] sdb1[1] sda1[0]
    5860535808 blocks level 5, 64k chunk, algorithm 2 [4/4] [UUUU]

md1 : active raid5 sdk1[3] sdj1[2] sdi1[1] sdh1[0]
    4395407808 blocks level 5, 64k chunk, algorithm 2 [4/4] [UUUU]

md3 : active raid5 sdl1[0] sdm1[1] sdf1[3] sde1[2]
    5860535808 blocks level 5, 64k chunk, algorithm 2 [4/4] [UUUU]

unused devices: <none>

Meu problema é que, pela segunda vez em três dias, uma das unidades de ataque está causando qualquer processo que tente ler a partir dele para travar. Nenhum sinal é capaz de terminar este processo, e tenho que reiniciar para que ele funcione novamente. No entanto, as unidades parecem bem após a reinicialização e o status da raid parece bom, e o log do kernel não tem nenhuma mensagem de erro útil além de que os processos estão travados.

Eu executei o smartctl em todas as unidades em questão e elas parecem boas.

O que mais posso verificar para tentar diagnosticar isso?

Aqui está uma exceção do log do kernel que parece semicinteressante. Mas note que o "não pode enviar ioctl para a partição" tem sido em torno de sempre, e as pesquisas revelaram que era um aviso inofensivo.

A cada 900 segundos:

...
Aug 20 18:34:01 [kernel] [  931.249505] mdadm: sending ioctl 1261 to a partition!
Aug 20 18:49:01 [kernel] [ 1831.302297] scsi_verify_blk_ioctl: 2 callbacks suppressed
Aug 20 18:49:01 [kernel] [ 1831.302300] mdadm: sending ioctl 1261 to a partition!
Aug 20 18:49:01 [kernel] [ 1831.302302] mdadm: sending ioctl 1261 to a partition!
Aug 20 18:49:01 [kernel] [ 1831.302774] mdadm: sending ioctl 1261 to a partition!
Aug 20 18:49:01 [kernel] [ 1831.302776] mdadm: sending ioctl 1261 to a partition!
Aug 20 18:49:02 [kernel] [ 1831.333538] mdadm: sending ioctl 1261 to a partition!
Aug 20 18:49:02 [kernel] [ 1831.333540] mdadm: sending ioctl 1261 to a partition!
Aug 20 18:49:02 [kernel] [ 1831.358068] mdadm: sending ioctl 1261 to a partition!
Aug 20 18:49:02 [kernel] [ 1831.358071] mdadm: sending ioctl 1261 to a partition!
Aug 20 18:49:02 [kernel] [ 1831.414331] mdadm: sending ioctl 1261 to a partition!
Aug 20 18:49:02 [kernel] [ 1831.414334] mdadm: sending ioctl 1261 to a partition!
Aug 20 19:04:01 [kernel] [ 2731.070794] scsi_verify_blk_ioctl: 2 callbacks suppressed
...

Sobre a hora em que o problema é exibido:

Aug 21 13:38:32 [kernel] [69601.312055] INFO: task kjournald:26008 blocked for more than 600 seconds.
Aug 21 13:38:32 [kernel] [69601.312057] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Aug 21 13:38:32 [kernel] [69601.312059] kjournald       D 00000000     0 26008      2 0x00000000
Aug 21 13:38:32 [kernel] [69601.312063]  eb5ccc80 00000046 00000000 00000000 00000000 e81e0070 e81e020c f6205900
Aug 21 13:38:32 [kernel] [69601.312068]  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
Aug 21 13:38:32 [kernel] [69601.312072]  00000000 00000000 00000000 00000000 00000000 00000001 c0b66230 e81e0280
Aug 21 13:38:32 [kernel] [69601.312077] Call Trace:
Aug 21 13:38:32 [kernel] [69601.312083]  [<c013cbe5>] ? prepare_to_wait+0x15/0x55
Aug 21 13:38:32 [kernel] [69601.312088]  [<c0217df5>] ? journal_commit_transaction+0xdb/0xca6
Aug 21 13:38:32 [kernel] [69601.312090]  [<c013ca68>] ? wake_up_bit+0x16/0x16
Aug 21 13:38:32 [kernel] [69601.312093]  [<c0132c3d>] ? lock_timer_base+0x19/0x35
Aug 21 13:38:32 [kernel] [69601.312095]  [<c0132cb8>] ? try_to_del_timer_sync+0x5f/0x65
Aug 21 13:38:32 [kernel] [69601.312098]  [<c021ade6>] ? kjournald+0xa6/0x1a2
Aug 21 13:38:32 [kernel] [69601.312101]  [<c013ca68>] ? wake_up_bit+0x16/0x16
Aug 21 13:38:32 [kernel] [69601.312103]  [<c021ad40>] ? journal_grab_journal_head+0x31/0x31
Aug 21 13:38:32 [kernel] [69601.312106]  [<c013c778>] ? kthread+0x65/0x6a
Aug 21 13:38:32 [kernel] [69601.312108]  [<c013c713>] ? kthread_stop+0x47/0x47
Aug 21 13:38:32 [kernel] [69601.312111]  [<c0830b36>] ? kernel_thread_helper+0x6/0xd
    
por dataless 22.08.2013 / 23:29

1 resposta

1

Primeiro atualize seu kernel. Esse kernel em particular continha um bug que fazia com que vários ioctls imprimissem esses avisos (e talvez falhar) em certas configurações de mdraid e LVM.

Se um kernel fixo não resolver o problema, execute um autoteste estendido em todas as suas unidades. Observe que o autoteste pode levar várias horas para cada unidade e diminuirá ligeiramente o desempenho durante a execução, portanto, deve ser executado em um momento de baixa atividade do sistema. Por exemplo, para programar os autotestes para começar às 11 da noite:

at 11 pm <<JOB
for drive in /dev/sd?
do
    smartctl -t long $drive || :
done
JOB

Mais tarde no dia seguinte, verifique os resultados do teste:

for drive in /dev/sd?
do
    echo Test results for drive $drive
    smartctl -l selftest $drive || :
done

Se a atualização do kernel não resolveu o problema, você pode encontrar uma unidade que falhou no autoteste.

Se você não encontrar uma unidade que falhou no autoteste, verifique os atributos da unidade de qualquer maneira.

for drive in /dev/sd?
do
    echo Attributes for drive $drive
    smartctl -A $drive || :
done

Observe que alguns desses atributos podem indicar problemas, mesmo que não estejam marcados como com falha; então encontre um especialista para examiná-los ou anexe-os à sua pergunta.

    
por 27.12.2013 / 09:12