linux - programa - Seleccionar la llamada del sistema se bloquea indefinidamente en una aplicación/w.

como usar crossover linux

Question

Tenemos una aplicación de red, se usará dentro de varios scripts para comunicarse con otros sistemas.

Ocasionalmente, las secuencias de comandos dependen de una llamada a nuestra aplicación de red. Recientemente tuvimos un problema y traté de depurar el proceso bloqueado de esta aplicación en particular.

Esta aplicación consta de un cliente y un servidor (un daemon), el bloqueo se produce en el lado del cliente.

La salida heterogénea me mostró que está colgada en una llamada al sistema de selección.

> strace -p 34567
select(4, [3], NULL, NULL, NULL

Como puede ver, no hay límite de tiempo en seleccionar la llamada, puede bloquearse indefinidamente si el descriptor de archivo ''3'' no está listo para la lectura.

La salida de lsof mostró que fd ''3'' está en estado FIN_WAIT2.

> lsof -p 34567
client  34567 user 3u  IPv4 55184032 TCP client-box:smar-se-port2->server:daemon (FIN_WAIT2)

¿La información anterior implica algo? FIN_WAIT2 estado? Comprobé por el lado del servidor (donde debería estar ejecutándose el proceso daemon correspondiente), pero no hay procesos daemon ejecutándose en el servidor. Supongo que el daemon se ejecutó correctamente y envió la salida al cliente, que debería estar disponible en fd ''3'' para lectura, pero la llamada de selección () en el cliente nunca sale y todavía espera que algo suceda.

No estoy seguro de por qué nunca sale de la llamada de selección (), esto solo ocurre ocasionalmente, la mayoría de las veces la aplicación funciona bien.

¿Alguna pista?

Tanto el servidor como el cliente son SuSE Linux.

Answer 1

FIN_WAIT2 significa que su aplicación ha enviado un paquete FIN al par, pero aún no ha recibido un FIN del par. En TCP, un cierre elegante requiere un FIN de ambas partes. El hecho de que el daemon del servidor no se esté ejecutando significa que el daemon salió (o fue eliminado) sin notificar a su par (usted). Por lo tanto, su select() está esperando paquetes que ya no recibirá, y tiene que esperar a que el sistema operativo invalide el socket utilizando un tiempo de espera interno, lo que puede llevar mucho tiempo. Este es el tipo de situación por la que nunca debe usar tiempos de espera infinitos. Use un tiempo de espera apropiado y actúe en consecuencia si transcurre el tiempo de espera.