
=========== Detalles del sistema ===========
SO: Solaris 10, actualización 11
CPU_ARCH: SPARC (sparcv9)
HW: Sun Fire V490 (Yeahhhh baby old school)
KERNEL_REV: 150400-40
Programa: bpbkar32 (Netbackup de Symantec)
TL;DR: No se pueden eliminar procesos incluso si kill -9
están SUSPENDIDOS zpool debido a que posiblemente no haya dos buenos caminos.
Asunto:
Tenemos un montón (16) de procesos que no se pueden eliminar en el sistema; El equipo de respaldo nos notificó que no podían eliminar estos trabajos del servidor NB Master ni generar nuevos respaldos, así que nos subimos e intentamos ./bp.kill_all
y recibimos:
bash-3.2#./bp.kill_all
Buscando procesos de NetBackup que deben finalizarse.
Matando procesos bpbkar...Los siguientes procesos siguen activos
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 dic 09? 0:00 bpbkar32 -r 8035200 -ru root -dt 0 -to 0 -bpstart_time 1481325879 -clnt nerp323
root 12618 1 0 dic 07? 0:00 bpbkar32 -r 2678400 -ru root -dt 357484 -to 0 -bpstart_time 1481077264 -clnt ne
root 29693 1 0 dic 09 ? 0:00 bpbkar32 -r 2678400 -ru root -dt 529430 -to 0 -bpstart_time 1481249210 -clnt ne
root 10168 1 0 dic 09 ? 0:00 bpbkar32 -r 2678400 -ru root -dt 530349 -to 0 -bpstart_time 1481250129 -clnt ne
root 1950 1 0 14 de diciembre? 0:00 bpbkar32 -r 2678400 -ru root -dt 962300 -to 0 -bpstart_time 1481682080 -clnt ne
¿Quieres que este script intente eliminarlos? [s,n] (y) y
Matando los procesos restantes...
Esperando que los procesos terminen...
Esperando que los procesos terminen...
Esperando que los procesos terminen...
Esperando que los procesos terminen...
Esperando procesos para terminar...
Hay procesos aún en ejecución.
... salida truncada para facilitar la lectura.
Lo que nos lleva a proceder a intentar acabar con esos procesos con prejuicios extremos, a través de kill -9
, también sin éxito. he mirado¿Cómo eliminar una tarea que no se puede eliminar (¿ininterrumpible?)y¿Qué pasa si 'kill -9' no funciona?así como también busqué en "Proceso ininterrumpible de Solaris" con resultados parciales. El reinicio parece ser el tema común y también parece ser nuestra solución de "golpear la cabeza contra el escritorio".
Dicho esto, me gustaría:
- validar mi lógica y razonamiento de cuál es la causa raíz
- ver si hay una mejor manera de determinar dónde se detiene el proceso/qué llamada al sistema está intentando ejecutar
- resolver la E/S sin reiniciar si es posible, y posteriormente aquellos procesos que no se pueden eliminar.
Prácticamente solo un análisis de la causa raíz y algún tipo de mitigación "En el futuro, no cambie el trabajo mientras se ejecutan las copias de seguridad o si no tiene dos rutas de trabajo".
Esto es lo que obtuve/lo que estoy pensando:
1) Accediendo al directorio /proc/1950/ y mirando el estado. No es difícil comprender ese resultado, incluso con strings
. Arroja caracteres aleatorios. Lo que hay que tener en cuenta es que 'cwd' muestra un enlace a nada, y al intentar resolverlo ls -alL /proc/1950/cwd
se bloqueará el terminal y también se crearáredoble de tamboresotro proceso ininterrumpible.
2) Ejecutar a pstack 1950
generará información útil, pero nada que no pueda ver ps -eaf
o que pueda entender. Sin embargo, todos los ceros se ven mal ya que no vemos direcciones ni llamadas al sistema como lo hago con un pid en funcionamiento.
bash-3.2#pstack 1950
1950: bpbkar32 -r 2678400 -ru root -dt 962300 -to 0 -bpstart_time 1481682080 00000000000000000 ???????? (0, 0, 0, 0, 0, 0)
3) La ejecución de a truss
se bloqueará si se intenta en el proceso en ejecución, lo mismo ocurre con pfiles
la generación de un error de "pfiles: no se puede controlar el proceso 1950". Interesante, pero esperado.
4) Ejecutar un strace
solo me dice que "ya existe un rastreador"
5) ejecutar a pwdx
para imprimir los resultados de cwd:
bash-3.2#pwdx 1950
1950: /cubo
Esto es interesante ya que nuestro df lo incluye...
df -h /bucket
Tamaño del sistema de archivos utilizado Capacidad de disponibilidad Montado en
el depósito 1,9 T 31 K 1,9 T 1 % / depósito
... pero intentar ingresar a /bucket y hacer un ls
produce el mismo efecto de suspensión.
bash-3.2#zpool list
NOMBRE TAMAÑO ALLOC FREE CAP HEALTH ALTROOT
balde 1.94T 308K 1.94T 0% SUSPENDIDO -
rpool 136G 58.0G 78.0G 42% EN LÍNEA -
bash-3.2#umount /bucket
no se puede abrir el 'depósito': la E/S del grupo está actualmente suspendida
bash-3.2#zpool export bucket
no se puede desmontar '/bucket': dispositivo ocupado
bash-3.2#zpool status -x
grupo:
estado del depósito:
estado SUSPENDIDO: uno o más dispositivos tienen fallas en respuesta a fallas de E/S.
Acción: Asegúrese de que los dispositivos afectados estén conectados y luego ejecute 'zpool clear'.
ver:http://www.sun.com/msg/ZFS-8000-HC
escaneo: ninguna configuración solicitada :
NOMBRE ESTADO LEER ESCRIBIR CKSUM
depósito SUSPENDIDO 0 0 0 experimentó fallas de E/S c3t50060E80102B1F5Ad78 FALLO 2 0 0 demasiados errores
Así que... siento que estamos muertos en el agua, y realmente que cuando ese "cambio de trabajo" estaba ocurriendo, NO había dos caminos activos/saludables hacia la SAN, por lo que terminamos tirando la alfombra desde abajo. el vdev y dio la casualidad de que la copia de seguridad estaba funcionando allí cuando murió, pero cualquier proceso, como el mío ls
, habría tenido el mismo comportamiento.
¿Alguien tiene alguna última idea sobre "ejecutar este comando desconocido que le evitará reiniciar"?
Respuesta1
Como sugirió Jeff, la limpieza de zpool debería ayudar a resolver el problema si las rutas han regresado. Como parece que no fue así, el servidor probablemente no pueda ver los LUN.
A zpool clear -F -n bucket
también le dirá si el grupo se puede importar descartando el último conjunto de transacciones (la opción -F).`
Mencionó el cambio de trabajo, por lo que es posible que desee verificar qué trabajo se realizó y si uno de los cambios eliminó alguna de las rutas. ¿Has mirado tu salida `luxadm display /dev/rdsk/c<____>s2? ¿O intentó reconfigurar las rutas con cfgadm? ¿O enviar un evento de labio forzado por un camino?
La salida completa de a zpool status bucket
también podría ser útil para determinar el tipo de grupo (espejo, gato, raya, ...). Supongo que no es un espejo según el problema.
Me doy cuenta de que es fácil para mí decirlo ya que no estoy en la mezcla, pero no entre en pánico todavía, ya que todos los datos deberían estar presentes en la matriz, asumiendo que no es el problema. Pero es posible que tengas que volver a importar con algunas de las transacciones revertidas.
¡Toda la suerte!
Respuesta2
Puede ver su estado de SAN (asumiendo FC SAN) con lo siguiente:
for port in `fcinfo hba-port | grep Port | awk '{ print $4 }'`; do
> fcinfo remote-port -ls -p $port
> done
Lea también elpágina de manual parampathadm
. Puede utilizar mpathadm show lu LUN
para mostrar el estado de un LUN.