
=========== Detalhes do sistema ===========
SO: Solaris 10, atualização 11
CPU_ARCH: SPARC (sparcv9)
HW: Sun Fire V490 (Sim, baby old school)
KERNEL_REV: 150400-40
Programa: bpbkar32 (Netbackup da Symantec)
TL; DR: Não é possível encerrar processos mesmo kill -9
devido a SUSPENSO zpool devido a possivelmente não dois bons caminhos.
Emitir:
Temos vários (16) processos que não podem ser eliminados no sistema; fomos notificados pela equipe de backup de que eles não poderiam eliminar esses trabalhos do servidor NB Master, nem gerar novos backups, então entramos e tentamos um ./bp.kill_all
e recebemos:
bash-3.2#./bp.kill_all
Procurando processos do NetBackup que precisam ser encerrados.
Matando processos bpbkar...Os seguintes processos ainda estão ativos
root 20346 1 0 02:02:33 ? 0:00 bpbkar32 -r 2678400 -ru root -dt 1047868 -to 0 -bpstart_time 1481767648 -clnt n
root 18689 1 0 09 de dezembro? 0:00 bpbkar32 -r 8035200 -ru root -dt 0 -to 0 -bpstart_time 1481325879 -clnt nerp323
root 12618 1 0 07 de dezembro? 0:00 bpbkar32 -r 2678400 -ru root -dt 357484 -to 0 -bpstart_time 1481077264 -clnt ne
root 29693 1 0 09 de dezembro? 0:00 bpbkar32 -r 2678400 -ru root -dt 529430 -to 0 -bpstart_time 1481249210 -clnt ne
root 10168 1 0 09 de dezembro? 0:00 bpbkar32 -r 2678400 -ru root -dt 530349 -to 0 -bpstart_time 1481250129 -clnt ne
root 1950 1 0 14 de dezembro? 0:00 bpbkar32 -r 2678400 -ru root -dt 962300 -to 0 -bpstart_time 1481682080 -clnt ne
Você deseja que este script tente matá-los? [y,n] (y) y
Matando os processos restantes...
Aguardando o término dos processos...
Aguardando o término dos processos...
Aguardando o término dos processos...
Aguardando o término dos processos...
Aguardando os processos para encerrar...
Ainda existem processos em execução.
... saída truncada para facilitar a leitura.
Levando-nos então a tentar matar esses processos com extremo preconceito, via kill -9
, também sem sucesso. eu olheiComo encerrar uma tarefa que não pode ser interrompida (ininterrupta?)eE se 'kill -9' não funcionar?bem como pesquisou "processo ininterrupto Solaris" com resultados parciais. A reinicialização parece ser o tema comum e também parece ser a nossa solução "bater a cabeça contra a mesa aqui".
Dito isto, gostaria de:
- validar minha lógica e raciocínio sobre qual é a causa raiz
- Ver se há uma maneira melhor de determinar onde o processo está interrompido/que chamada de sistema ele está tentando executar
- Resolver a E/S sem reinicialização, se possível, e subsequentemente aqueles processos que não podem ser eliminados.
Praticamente apenas uma análise de causa raiz e algum tipo de mitigação "No futuro, não alterne o trabalho enquanto os backups estiverem em execução ou se você não tiver dois caminhos de trabalho".
Aqui está o que eu tenho/o que estou pensando:
1) Entrando no diretório /proc/1950/ e olhando o status. Não há dados para entender essa saída, mesmo com strings
. Vomita caracteres aleatórios. O que vale a pena notar é que 'cwd' mostra um link para nada, e tentar resolvê-lo ls -alL /proc/1950/cwd
travará o terminal e também criarárufar de tamboresoutro processo ininterrupto.
2) Executar a pstack 1950
gerará algumas informações úteis, mas nada que eu não possa ver ps -eaf
ou que possa entender. Porém, todos os zeros parecem ruins, pois não vemos endereços ou syscall como eu faço com um pid funcional.
bash-3.2#pstack 1950
1950: bpbkar32 -r 2678400 -ru root -dt 962300 -to 0 -bpstart_time 1481682080 000000000000000 ???????? (0, 0, 0, 0, 0, 0)
3) A execução de um truss
irá travar se for tentada no processo em execução, idem para pfiles
gerar um erro de "pfiles: não é possível controlar o processo 1950". Interessante, mas esperado.
4) Executar strace
apenas me diz que um "rastreador já existe"
5) executando um pwdx
para imprimir os retornos do cwd:
bash-3.2#pwdx 1950
1950: /balde
Isso é interessante porque nosso df inclui isso ...
df -h /bucket
Tamanho do sistema de arquivos usado capacidade disponível Montado no
bucket 1,9T 31K 1,9T 1% /bucket
... mas tentar fazer cd em /bucket e fazer an ls
produz o mesmo efeito de suspensão.
bash-3.2#zpool list
NOME TAMANHO ALLOC FREE CAP HEALTH ALTROOT
balde 1.94T 308K 1.94T 0% SUSPENSO -
rpool 136G 58,0G 78,0G 42% ONLINE -
bash-3.2#umount /bucket
não é possível abrir o 'balde': a E/S do pool está atualmente suspensa
bash-3.2#zpool export bucket
não é possível desmontar '/ bucket': dispositivo ocupado
bash-3.2#zpool status -x
pool:
estado do bucket:
status SUSPENSO: um ou mais dispositivos apresentam falha em resposta a falhas de E/S.
ação: Certifique-se de que os dispositivos afetados estejam conectados e execute 'zpool clear'.
ver:http://www.sun.com/msg/ZFS-8000-HC
varredura: nenhuma configuração solicitada :
NAME STATE READ WRITE CKSUM
bucket SUSPENDED 0 0 0 ocorreram falhas de E/S c3t50060E80102B1F5Ad78 FAULTED 2 0 0 muitos erros
Entããão... Estou sentindo que estamos mortos na água, e realmente que quando aquele "trabalho de troca" estava acontecendo, NÃO havia dois caminhos ativos/saudáveis para a SAN, e então acabamos puxando o tapete por baixo o vdev e aconteceu que o backup estava funcionando lá quando morreu, mas qualquer processo, como o meu ls
, teria o mesmo comportamento.
Alguém tem alguma última ideia de "executar este comando desconhecido que irá poupar uma reinicialização" ???
Responder1
Conforme sugerido por Jeff, o zpool clear deve ajudar a resolver o problema se o(s) caminho(s?) tiver(em) retornado(s). Como parece que não, o servidor provavelmente não consegue ver o (s) LUN (s).
A zpool clear -F -n bucket
também informará se o pool pode ser importado descartando o último conjunto de transações (a opção -F).`
Você mencionou o trabalho do switch, então você pode querer verificar qual trabalho foi feito e se uma das alterações removeu algum dos caminhos. Você olhou sua saída `luxadm display /dev/rdsk/c<____>s2 ? Ou tentei reconfigurar os caminhos com cfgadm? Ou enviando um evento forcelip por um caminho?
A saída completa de a zpool status bucket
também pode ser útil para determinar o tipo de pool (espelho, gato, faixa, ...). Presumo que não seja um espelho com base no problema.
Sei que é fácil dizer, já que não estou no mix, mas não entre em pânico ainda, pois os dados ainda devem estar presentes no array, presumindo que não seja o problema. Mas você pode acabar tendo que reimportar algumas das transações revertidas.
Boa sorte!
Responder2
Você pode ver o status do seu SAN (assumindo FC SAN) com o seguinte:
for port in `fcinfo hba-port | grep Port | awk '{ print $4 }'`; do
> fcinfo remote-port -ls -p $port
> done
Além disso, leia opágina de manual parampathadm
. Você pode usar mpathadm show lu LUN
para mostrar o status de um LUN.