netstat -ntap n'affiche pas le nom pid / process pour certaines connexions?

10

J'ai un serveur ubuntu / hardy, avec le noyau 2.6.24-23-server et netstat:

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

Le problème est que nous avons beaucoup de connexions ESTABLISHED qui ne montrent pas le PID ni le nom du programme en netstat -ntapsortie. Netstat a été appelé depuis root, il n'y a pas de chroots, de grsecurity, ni rien de ce genre (du moins, m'a-t-on dit :).

Avez-vous une idée de ce qui pourrait être faux?

METTRE À JOUR

lsof -n -i fonctionne correctement et affiche le nom pid / process pour les connexions.

linux networking ubuntu netstat
la source
2
Êtes-vous sûr de l'exécuter en tant que root ou avec sudo?
Dom
Oui, il a été exécuté sur root, et même sur root via sudo. même effet.
Etes-vous sûr que vous ne faisiez pas à la netstat -ntapplace de netstat ntap?
Kyle Brandt
Je suis sûr que je faisais netstat -ntap- comme je l'ai écrit. car c'est la façon dont les options sont données à netstat selon sa page de manuel.
Note latérale - je viens de vérifier et il semble que netstat ne reconnaisse pas les options données sans "-".

Réponses:

4

Cela se produira avec des processus du noyau comme NFS, mais se produit également occasionnellement avec des applications régulières: RHEL 5 a le même comportement. 

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

Notez que lsof, d'autre part, les mots correctement:

# lsof -i:30715
AppName 1598 useracct   78u     IPv4           81467710                   TCP *:30715 (LISTEN)
mikemaccana
la source
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:~ #

à mon avis, il pourrait y avoir deux situations:

1) l'utilisateur privilégié normal excute "netstat" ne peut pas voir les processus lancés par root

2) certains processus s'exécutent dans le noyau

Yans Ruan
la source
1

Pour les connexions établies, cela ne devrait se produire que pour les connexions qui sont lancées à partir de l'espace du noyau, comme NFS ou DRBD. De toute évidence, les connexions en attente auraient pu faire mourir le processus en dessous. Si vous ne pouvez pas déterminer la cause d'une connexion donnée, collez la sortie et quelqu'un peut vous dire de quoi il s'agit.

womble
la source
Ce ne sont certainement pas des connexions basées sur le noyau car ce sont des connexions à la base de données à partir de l'application.
Sortie de netstat -atnp | grep EST?
womble
c'est ce que mon problème est - les connexions sont répertoriées par au lieu du nom pid / programme j'ai "-"
3
Et j'aimerais voir ce qui se passe réellement , plutôt qu'une interprétation de celui-ci.
womble
Je ne peux pas vous montrer la sortie entière car elle contient des noms qui pourraient être utilisés pour identifier l'environnement. la ligne pour ce port particulier ressemble à ceci: "tcp 0 0 localhost: 36949 localhost: 6543
1

J'ai le même comportement et je suppose que le comportement netstat peut avoir changé. Par exemple, je vois le port et le programme pour 'wget', mais pas pour les processus PHP Apache, qui sont les plus importants pour moi.

Solution: j'ai réécrit mon script pour utiliser lsof à la place (voir l'indice ci-dessus)


la source
Pascal: Avez-vous exécuté cette commande avec sudo ou en tant que root?
Stefan Lasiewski
0

J'arrive ici car ces jours-ci je rencontre la même question sur ubuntu 18.04 LTS (netstat est la même version netstat 1.42 (2001-04-15)), étrange toujours pas de réponse après 8 ans. Après avoir parcouru le code source de net-tools, je peux le trouver.

Dans le code source netstat:

  1. tous les dossiers de processus dans / proc sont itérés, chaque fd dans le répertoire / proc // fd est vérifié pour construire une carte de l'inode de socket vers pid / progname.

  2. Ensuite, / proc / net / tcp est vérifié pour obtenir les informations de socket tcp (par la fonction tcp_info), y compris l'inode de socket.

  3. lors de la sortie des informations de socket tcp, le pid / progname est interrogé à partir de la carte à l'étape 1 via l'inode de socket. si rien n'est trouvé, '-' sort.

Si le socket est créé après la construction de la carte, le pid / progname ne sera pas trouvé dans la carte.

zenkj
la source