=========== Detalhes do sistema ===========
SO: Solaris 10, atualização 11
CPU_ARCH: SPARC (sparcv9)
HW: Sun Fire V490 (Yeahhhh baby old school)
KERNEL_REV: 150400-40
Programa: bpbkar32 (Netbackup da Symantec)
TL; DR: Não é possível matar processos mesmo com kill -9 devido ao zpool SUSPENDED devido a possivelmente não dois bons caminhos.
Problema:
Nós temos um monte (16) de processos inutilizáveis no sistema; Nós fomos notificados pela equipe de backup que eles não podiam matar esses trabalhos do servidor mestre do NB, nem gerar novos backups, então nós pulamos e tentamos um ./bp.kill_all e recebemos:
bash-3.2 # ./bp.kill_all
Looking for NetBackup processes that need to be terminated.
Killing bpbkar processes...
The following processes are still active
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 Dec 09 ? 0:00 bpbkar32 -r 8035200 -ru root -dt 0 -to 0 -bpstart_time 1481325879 -clnt nerp323
root 12618 1 0 Dec 07 ? 0:00 bpbkar32 -r 2678400 -ru root -dt 357484 -to 0 -bpstart_time 1481077264 -clnt ne
root 29693 1 0 Dec 09 ? 0:00 bpbkar32 -r 2678400 -ru root -dt 529430 -to 0 -bpstart_time 1481249210 -clnt ne
root 10168 1 0 Dec 09 ? 0:00 bpbkar32 -r 2678400 -ru root -dt 530349 -to 0 -bpstart_time 1481250129 -clnt ne
root 1950 1 0 Dec 14 ? 0:00 bpbkar32 -r 2678400 -ru root -dt 962300 -to 0 -bpstart_time 1481682080 -clnt ne
Do you want this script to attempt to kill them? [y,n] (y) y
Killing remaining processes...
Waiting for processes to terminate...
Waiting for processes to terminate...
Waiting for processes to terminate...
Waiting for processes to terminate...
Waiting for processes to terminate...
There are processes still running.
... saída truncada para legibilidade.
Levando-nos a prosseguir para tentar matar esses processos com extremo preconceito, via kill -9 , também sem sucesso.
Eu olhei para Como matar uma tarefa que não pode ser morto (ininterrupto?) e E se? kill -9 'não funciona? e pesquisado em "processo uninterruptable do Solaris" com resultados parciais. A reinicialização parece ser o tema comum e uma que parece ser nossa solução "bater a cabeça contra a mesa aqui" também.
Assim sendo, eu gostaria de:
- validar minha lógica e raciocínio sobre a causa raiz
- Veja se há uma maneira melhor de determinar onde o processo está parado / o que o sys chama está tentando executar.
- Resolva a E / S sem uma reinicialização, se possível, e subsequentemente, os processos que não podem ser eliminados.
Praticamente apenas uma análise de causa raiz e algum tipo de atenuaçã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) Popping no diretório / proc / 1950 / e olhando para o status. Não há dados com a compreensão dessa saída, mesmo com strings . Spews caracteres aleatórios.
A coisa de nota é que 'cwd' mostra um link para nada, e tentar resolvê-lo via ls -alL /proc/1950/cwd irá travar o terminal e também criar drumroll outro processo ininterrupto.
2) A execução de um pstack 1950 gerará algumas informações úteis, mas nada que eu não possa ver de um ps -eaf ou que eu possa entender. Todos os zeros, porém, parece ruim, pois não vemos endereços ou syscall como eu faço com um pid de trabalho.
bash-3.2 # pstack 1950
1950: bpbkar32 -r 2678400 -ru root -dt 962300 -to 0 -bpstart_time 1481682080
0000000000000000 ???????? (0, 0, 0, 0, 0, 0)
3) A execução de um truss será interrompida se for tentada no processo em execução, idem para pfiles gerando um erro de "pfiles: cannot control process 1950". Interessante, mas esperado.
4) A execução de um strace apenas me diz que um "rastreador já existe"
5) executando um pwdx para imprimir os retornos cwd:
bash-3.2 # pwdx 1950
1950: /bucket
Isso é interessante, pois nosso df inclui isso ...
df -h /bucket
Filesystem size used avail capacity Mounted on
bucket 1.9T 31K 1.9T 1% /bucket
... mas tentar fazer cd no / bucket e fazer um ls produz o mesmo efeito de suspensão.
bash-3.2 # zpool list
NAME SIZE ALLOC FREE CAP HEALTH ALTROOT
bucket 1.94T 308K 1.94T 0% SUSPENDED -
rpool 136G 58.0G 78.0G 42% ONLINE -
bash-3.2 # umount /bucket
cannot open 'bucket': pool I/O is currently suspended
bash-3.2 # zpool export bucket
cannot unmount '/bucket': Device busy
bash-3.2 # zpool status -x
pool: bucket
state: SUSPENDED
status: One or more devices are faulted in response to IO failures.
action: Make sure the affected devices are connected, then run 'zpool clear'.
see: http://www.sun.com/msg/ZFS-8000-HC
scan: none requested
config:
NAME STATE READ WRITE CKSUM
bucket SUSPENDED 0 0 0 experienced I/O failures
c3t50060E80102B1F5Ad78 FAULTED 2 0 0 too many errors
Sooo ... Estou sentindo que estamos mortos na água, e realmente que quando esse "switch work" estava acontecendo, não havia dois caminhos ativos / saudáveis para a SAN, e então acabamos puxando o tapete de debaixo do vdev e aconteceu que o backup estava funcionando lá quando ele morreu, mas qualquer processo, como meu ls , teria o mesmo comportamento.
Alguém tem algum último pensamento salvador de "executar este comando desconhecido que salvará você de uma reinicialização" ???