Zoccoli trovati da lsof ma non da netstat

Ho un'applicazione che sta esaurendo i descrittori di file, apparentemente aprendo socket, ma non riesco a scoprire esattamente cosa fanno questi socket. Questi appaiono nell'output di lsof come

java    9689 appuser 1010u  sock       0,5          263746675 can't identify protocol
java    9689 appuser 1011u  sock       0,5          263746676 can't identify protocol
java    9689 appuser 1012u  sock       0,5          263746677 can't identify protocol
java    9689 appuser 1014u  sock       0,5          263746678 can't identify protocol
java    9689 appuser 1015u  sock       0,5          263746679 can't identify protocol
java    9689 appuser 1016u  sock       0,5          263746681 can't identify protocol

e in / proc / $ PID / fd come

lrwx------ 1 appuser appuser 64 Jun 23 11:49 990 -> socket:[263732085]
lrwx------ 1 appuser appuser 64 Jun 23 11:49 991 -> socket:[263732086]
lrwx------ 1 appuser appuser 64 Jun 23 11:49 992 -> socket:[263735307]
lrwx------ 1 appuser appuser 64 Jun 23 11:49 993 -> socket:[263732088]
lrwx------ 1 appuser appuser 64 Jun 23 11:49 995 -> socket:[263735308]
lrwx------ 1 appuser appuser 64 Jun 23 11:49 996 -> socket:[263735309]
lrwx------ 1 appuser appuser 64 Jun 23 11:49 997 -> socket:[263745434]
lrwx------ 1 appuser appuser 64 Jun 23 11:49 998 -> socket:[263745435]
lrwx------ 1 appuser appuser 64 Jun 23 11:49 999 -> socket:[263745436]

ma non esiste un output simile in netstat -a.

Cosa sono queste prese e come posso sapere cosa fanno?

Modifica : ho provato a correre grep $SOCKET /proc/net, come raccomandato nelle FAQ di lsof , dove $ SOCKET è ad esempio 263746679, ma anche questo non ha dato risultati.

Come sfondo, l'applicazione è un contenitore per più attività che, tra le altre, eseguono chiamate di rete. Devo individuare quello che impazzisce, ma fino a quando non scopro con chi comunicano quelle prese, sono bloccato.

Ciò può verificarsi se si crea un socket, ma non si connette mai () o bind () con esso. La soluzione migliore potrebbe essere quella di rintracciare (-fF) l'applicazione e quindi fare un riferimento incrociato con l'output di lsof per determinare quali socket stanno causando il problema. Come metodo bonus di debug: se si avvolgono le chiamate del socket con le informazioni di debug e le si scrivono in / dev / null, appariranno in sequenza senza darti file di registro esilaranti.

Usando Python, ho riscontrato lo stesso problema sui socket SSL:

• Quando uso socket.close (), il socket rimane nello stato CLOSE_WAIT per un tempo indefinito
• quando uso socket.shutdown (), lsof dice "impossibile identificare il protocollo"

La soluzione era di scartare il livello SSL prima di chiudere:

• origsock = socket.unwrap ()
• origsock.close ()

Questo chiude correttamente le prese nella mia app.

La prima cosa che vorrei fare è annullare se il limite del descrittore di file:

~# vi /etc/sysctl.conf
fs.file-max = 331287

Quindi mi assicurerò che il tuo sistema sia aggiornato, questo include tutte le librerie e i server. È possibile che il server delle applicazioni Java non sia aggiornato (se ne usi uno). È anche possibile che il tuo server delle applicazioni sia configurato in modo errato, dovresti guardare il tuo file di configurazione e abbassare il tuo connectionTimeoute / o il tuo maxKeepAliveRequests(non sono sicuro di quale server applicazioni stai usando o se ne stai usando uno ...).

Non sono sicuro di cosa faccia questa applicazione, ma se non pensi che richieda decine di migliaia di socket, questa è quasi certamente una "perdita di descrittore di file" nella tua applicazione Java. Potrebbe essere necessario inviare una segnalazione di bug al fornitore. In questa segnalazione di bug è necessario includere informazioni su come ricreare il problema.

Ecco alcuni modi per eseguire il debug del problema.

Wireshark (o twireshark per il cli) è lo strumento migliore per vedere come vengono utilizzati questi socket. Wireshark ti darà una panoramica del tipo di traffico che viene lanciato sul filo. È probabile che le prime connessioni abbiano esito positivo e quindi colpirà il limite del descrittore di file. Una volta raggiunto il limite del descrittore di file, Wireshark non raccoglierà nulla (e neat è netstat per quella materia), ma ciò contribuirà a restringere il problema. In alcuni casi è possibile che vengano inviati molti SYN in uscita, tuttavia non vengono ricevuti SYN / ACK, pertanto molte connessioni tcp sono bloccate nello stato SYN_WAIT.

Se si ha accesso al codice sorgente e si conosce il tipo di socket in fase di creazione (come l'utilizzo di strace o la ricerca del codice), è possibile aprire il progetto in Eclipse (o un altro IDE) e impostare un punto di interruzione nella funzione che sta creando questi socket. Quando il punto di interruzione viene colpito, puoi guardare la traccia dello stack. Questo descrittore di file perde forse un semplice ciclo infinito o forse il valore di timeout del socket è troppo grande. Un'altra possibilità è che l'app java non stia eseguendo un'operazione socket.close()di pulizia delle connessioni. Fare una chiusura è comunemente fatto nel finelyblocco di un try/catch(Sì, un socket deve sempre avere un tentativo / cattura in Java o non si costruirà :). Alla fine della giornata è probabile che l'app Java non gestisca correttamente le sue IOException.