netstat -ntap no muestra el nombre pid / proceso para algunas conexiones?

10

Tengo un servidor ubuntu / hardy, con kernel 2.6.24-23-server y netstat:

# netstat --version
net-tools 1.60
netstat 1.42 (2001-04-15)

El problema es que tenemos muchas conexiones ESTABLECIDAS que no muestran PID ni el nombre del programa en la netstat -ntapsalida. Netstat fue llamado desde la raíz, no hay chroots, seguridad, ni nada de esto (o eso me dijeron :).

¿Alguna idea de lo que podría estar mal?

ACTUALIZAR

lsof -n -i funciona bien y muestra el nombre pid / proceso para las conexiones.

2

¿Estás seguro de ejecutarlo como root o con sudo?

— Dom

Sí, se ejecutó en root e incluso en root a través de sudo. mismo efecto

¿Estás seguro de que no estabas haciendo en netstat -ntaplugar de netstat ntap?

— Kyle Brandt

Estoy seguro de que lo estaba haciendo netstat -ntap, tal como lo escribí. como esta es la forma en que se dan las opciones a netstat de acuerdo con su página de manual.

Nota al margen: acabo de comprobar y parece que netstat no reconoce las opciones dadas sin "-".

4

Esto ocurrirá con procesos del kernel como NFS, pero también ocurre ocasionalmente con aplicaciones normales: RHEL 5 tiene el mismo comportamiento.

# netstat -taupen | grep 30715
tcp        0      0 0.0.0.0:30715           0.0.0.0:*               LISTEN      66558      81467710   -

Tenga en cuenta que lsof, por otro lado, las palabras correctamente:

# lsof -i:30715
AppName 1598 useracct   78u     IPv4           81467710                   TCP *:30715 (LISTEN)

— mikemaccana
fuente

3

198_141:~ # netstat  -anp|grep 33000
tcp        0      0 0.0.0.0:53000           0.0.0.0:*               LISTEN       -                   
198_141:~ # lsof -i:33000
COMMAND   PID USER   FD   TYPE     DEVICE SIZE NODE NAME
vsftpd  28147 root    3u  IPv4 4089990174       TCP *:33000 (LISTEN)
198_141:~ # id
uid=0(root) gid=100(users) groups=16(dialout),100(users)
198_141:~ #

en mi cebolla, podría haber dos situaciones:

1) el usuario con privilegios normales excute "netstat" no puede ver los procesos iniciados por root

2) algunos procesos se ejecutan en el núcleo

— Yans Ruan
fuente

1

Para las conexiones establecidas, esto solo debería suceder para las conexiones que se inician desde el espacio del kernel, como NFS o DRBD. Obviamente, las conexiones en espera podrían haber hecho que el proceso muriera debajo de ellas. Si no puede determinar qué está causando una conexión determinada, pegue la salida y alguien puede decirle qué es.

— womble
fuente

Estas definitivamente no son conexiones basadas en el núcleo, ya que son conexiones a la base de datos desde la aplicación.

Salida de netstat -atnp | grep EST?

— womble

este es mi problema: las conexiones se enumeran por en lugar de pid / nombre del programa que tengo "-"

3

Y me gustaría ver lo que realmente está sucediendo, en lugar de una interpretación de esto.

— womble

No puedo mostrarle toda la salida, ya que contiene nombres que podrían usarse para identificar el entorno. la línea para este puerto en particular se ve así: "tcp 0 0 localhost: 36949 localhost: 6543 ESTABLISHED -"

1

Tengo el mismo comportamiento y creo que el comportamiento de netstat puede haber cambiado. Por ejemplo, veo el puerto y el programa para 'wget', pero no para los procesos de Apache PHP, que son los más importantes para mí.

Solución alternativa: reescribí mi script para usar lsof en su lugar (vea la sugerencia anterior)

Pascal: ¿Ejecutaste este comando con sudo o como root?

— Stefan Lasiewski

0

Llegue aquí porque en estos días me encuentro con la misma pregunta en ubuntu 18.04 LTS (netstat es la misma versión netstat 1.42 (15/04/2001)), extraño aún no hay respuesta después de 8 años. Después de examinar el código fuente de net-tools, puedo encontrarlo.

En el código fuente de netstat:

todas las carpetas de proceso en / proc se repiten, cada fd en el directorio / proc // fd se verifica para construir un mapa desde el inodo del socket al pid / progname.
entonces / proc / net / tcp se verifica para obtener información del socket tcp (mediante la función tcp_info), incluido el inodo del socket.
al generar la información del socket tcp, el pid / progname se consulta desde el mapa en el paso 1 a través del inodo del socket. si no se encuentra nada, '-' sale.

Si el socket se crea después de construir el mapa, el nombre pid / prog no se encontrará en el mapa.

— zenkj
fuente