1. strace -p [número de proceso]
strace -p 1002297
strace: Process 1002297 attached
futex(0x7fcbb95f3f84, FUTEX_WAIT_PRIVATE, 1, NULLPuedes ver que murió en futex (0x7fcbb95f3f84, FUTEX_WAIT_PRIVATE, 1, NULL
Utilice strace para encontrar un ejemplo de la causa del proceso atascado
Recientemente me encontré con una situación en la que el proceso está atascado, pero es posible que no pueda reproducirse en el proceso de depuración por mí mismo. Solo se activará bajo ciertas condiciones después de ejecutarse durante un período de tiempo. Para este tipo de situación en la que el La operación no puede dañar la escena, podemos usar gdb -p y strace -p para rastrear.
Primero, usamos ps auxf para ver dónde se ha ejecutado nuestro proceso :
Puede ver que la ejecución llega a docker exec -i 178.20.1.229_0115034556 ls y luego se atasca
Luego usamos strace para ver qué devolución de llamada del sistema ha ejecutado esta operación :
Aquí puede ver que está muerto en la lectura de devolución de llamada del sistema. El significado específico del descriptor 19 se puede verificar ingresando / proc / pid / fd :
Podemos encontrar que 19 representa la tubería, y estamos muertos aquí en la tubería de lectura.
/ ********************************************** *********************************************** ***************************** /
Línea divisoria, este problema reaparece más tarde,
primero usamos ps auxf para verificar el número de proceso y el proceso se ha ejecutado En qué paso , puede ver que el número de proceso es 27678, que está atascado en docker exec
root 27678 0.3 0.4 512172 16500 Sl python /wns/cloud/app/com_host/main.pyc
root 25011 0.0 0.0 4332652 S \ _ / bin / sh -c docker exec -i mongo_docker_master ls
root 25014 0.0 0.2 136592 10600 Sl \ _ docker exec -i mongo_docker_master ls
continuó rastreando con strace -p 27678 y encontró que estaba atascado en lectura y el descriptor de archivo era 14
root @ localhost: / # strace -p 27678
Proceso 27678
lectura adjunta (14,
luego cd / proc / 27678 / , aquí podemos ver el estado del proceso
root @ localhost: / proc / 27678 # cat status
Nombre: python
State: S (durmiendo)
Tgid: 27678
Ngid: 0
Pid: 27678
PPid: 27677
Ver la información de depuración de la pila del kernel del proceso , wchan representa la función que causó el proceso dormir o esperar
root @ localhost: / proc / 27678 # cat pila
[<ffffffff811a91ab>] pipe_wait + 0x6b / 0x90
[<ffffffff811a9c04>] pipe_read + 0x344 / 0x4f0
[<ffffffff811a00bf>] do_sync_read + 0x7f / 0xB0
[<ff0ff> 0x130
[<ffffffff811a1110> ] SyS_read + 0x80 / 0xe0
[<ffffffff818d4c49>] system_call_fastpath + 0x16 / 0x1b
[<ffffffffffffffff>] 0xffffffffffffffff
root @ localhost: / proc / 27678 # cat wchan
pipe_wait
now 14 ¿Qué significa, archivo de tubería?
root @ localhost: / proc / 27678 # ls -l ./fd
total 0
lr-x ------ 1 root root 64 26 de marzo 17:19 0 -> pipe: [30690124]
l-wx ---- - 1 raíz raíz 64 26 de marzo 17:19 1 -> tubería: [30690125]
lrwx ------ 1 raíz raíz 64 26 de marzo 17:19 10 -> socket: [30691732]
lr-x ---- - 1 raíz raíz 64 26 de marzo 17:19 11 -> / dev / urandom
lrwx ------ 1 raíz raíz 64 26 de marzo 17:19 12 -> socket: [30719611]
lrwx ------ 1 raíz raíz 64 26 de marzo 17:19 13 -> socket: [30719610]
lr-x ------ 1 root root 64 26 de marzo 17:19 14 -> pipe: [38483750]
Ya podemos confirmar que main crea procesos secundarios Ejecutar el comando de shell docker exec -i mongo_docker_master ls, y comunicarse con el proceso hijo a través de la tubería al mismo tiempo, y el resultado se atasca en la tubería de lectura.
De hecho, también podemos usar lsof para ubicar aquí, podemos ver que el FD 14 abierto por el proceso 27678 es pipe, donde u significa legible y escribible, y r significa legible
sangfor ~ # lsof -d 14
COMANDO PID USUARIO TIPO FD TAMAÑO DEL DISPOSITIVO / APAGADO NODO NOMBRE
mongod 1907 root 14u REG 251,0 36864 130683 /wns/data/mongodb/db/collection-7--588642557116981989.wt
syslog-ng 3446 root 14u UNIX 0xffff88012227d800 0T0 40557736 / dev / log
dockerd 4025 14u raíz UNIX 0xffff8800b8d5d800 0T0 13941 /run/docker/libnetwork/a73bd949b5fbb89c2b8bec3b4ac6af0a948a944958c8b037d9e6c9b324b44331.sock
ventana acoplable co-9382 de raíz 14u 0000 0,9 0 9553 anon_inode
ventana acoplable co-21204 raíz 14u 0000 0,9 0 9553 anon_inode
python 27678 root 14r FIFO 0,8 0t0 38483750 tubería
También puede ver directamente el proceso 27678 abierto, puede ver que 14 es tubería
sangfor ~ # lsof -p 27678
COMANDO PID USUARIO FD TIPO DE DISPOSITIVO TAMAÑO / NOMBRE DE NODO APAGADO
python 27678 root 0r FIFO 0,8 0t0 30690124 pipe
python 27678 root 1w FIFO 0,8 0t0 30690125 pipe
python 27678 root 2w FIFO 0,8 0t0 3069012 pipe
python 27678 root 3u 0000 0,9 0 9553 anon_inode
python 27678 root 4u 0000 0,9 0 9553 anon_inode
python 27678 root 5u paquete 30691718 0t0 tipo desconocido = SOCK_RAW
python 27678 root 6w REG 251,0 76106652 130565 / wns / data / com_host /etc/config/err.log
python 27678 root 7u IPv4 30691716 0t0 TCP Sangfor: 53102-> Sangfor: 42457 (ESTABLECIDO)
python 27678 root 8u IPv4 30691717 0t0 TCP Sangfor: 42457-> Sangfor: 53102 (ESTABLECIDO)
python 27678 root d1731 IPt0 3069 54072-> sdwan.io:27017 (ESTABLECIDO)
python 27678 root 10u IPv4 30691732 0t0 TCP db.sdwan: 54074-> sdwan.io:27017 (ESTABLECIDO)
python 27678 root 11r CHR 1,9 0t0 30690329 / dev / urandom
python 2767 root 12u IPv4 30719611 0t0 TCP db.sdwan: 51404-> db.sdwan: 37017 (ESTABLECIDO)
python 27678 root 13u IPv4 30719610 0t0 TCP db.sdwan: 47124-> db.sdwan: 27017 (ESTABLECIDO)
python 27678 root 14r FIFO 0,8 0t0 38483750 pipe
————————————————
Enlace original: https://blog.csdn.net/peng314899581/article/details/79064616