netstat -ntap không hiển thị tên pid / process cho một số kết nối?


10

Tôi có máy chủ Ubuntu / hardy, với kernel 2.6.24-23-server và netstat:

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

Vấn đề là chúng ta có rất nhiều kết nối THÀNH LẬP không hiển thị tên PID cũng như tên chương trình trong netstat -ntapđầu ra. Netstat được gọi từ root, không có chroots, grsecurance, cũng không có gì như thế này (hoặc vì vậy tôi đã nói với :).

Bất cứ ý tưởng về những gì có thể sai?

CẬP NHẬT

lsof -n -i hoạt động tốt, và hiển thị tên pid / process cho các kết nối.


2
Bạn có chắc chắn để chạy nó như root hoặc với sudo?
Dom

Vâng, nó đã được chạy trên root và thậm chí trên root thông qua sudo. cùng tác dụng.

Bạn có chắc là bạn không làm netstat -ntapthay vì netstat ntap?
Kyle Brandt

Tôi chắc chắn rằng tôi đã làm netstat -ntap- giống như tôi đã viết. vì đây là cách các tùy chọn được đưa ra cho netstat theo trang man của nó.

Lưu ý bên lề - tôi vừa kiểm tra và có vẻ như netstat không nhận ra các tùy chọn được đưa ra mà không có "-".

Câu trả lời:


4

Điều này sẽ xảy ra với các quy trình kernel như NFS, nhưng đôi khi cũng xảy ra với các ứng dụng thông thường: RHEL 5 có hành vi tương tự.

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

Lưu ý rằng lsof, mặt khác, các từ đúng:

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

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:~ # 

trong hành trình của tôi, có thể có hai tình huống:

1) người dùng đặc quyền bình thường loại bỏ "netstat" không thể thấy các quy trình được khởi chạy bởi root

2) một số tiến trình chạy trong kernel


1

Đối với các kết nối được thiết lập, điều này chỉ xảy ra đối với các kết nối được bắt đầu từ không gian kernel, như NFS hoặc DRBD. Rõ ràng các kết nối chờ đợi có thể đã có quá trình chết bên dưới chúng. Nếu bạn không thể tìm ra nguyên nhân gây ra kết nối cụ thể, hãy dán đầu ra và ai đó có thể cho bạn biết đó là gì.


Đây chắc chắn không phải là các kết nối dựa trên kernel vì đây là các kết nối đến cơ sở dữ liệu từ ứng dụng.

Đầu ra của netstat -atnp | grep EST?
womble

đây là vấn đề của tôi - các kết nối được liệt kê thay vì pid / tên chương trình tôi có "-"

3
Và tôi muốn xem những gì đang thực sự xảy ra, hơn là một cách giải thích.
womble

Tôi không thể hiển thị cho bạn toàn bộ đầu ra vì nó chứa các tên có thể được sử dụng để xác định môi trường. dòng cho cổng cụ thể này trông như thế này: "tcp 0 0 localhost: 36949 localhost: 6543 THÀNH LẬP -"

1

Tôi có hành vi tương tự và tôi đoán là hành vi netstat có thể đã thay đổi. Ví dụ, tôi thấy cổng và chương trình cho 'wget', nhưng không phải cho các quy trình PHP của Apache, thứ quan trọng hơn đối với tôi.

Giải pháp thay thế: Tôi viết lại kịch bản của mình để sử dụng lsof thay thế (xem gợi ý ở trên)


Pascal: Bạn đã chạy lệnh này với sudo hay root chưa?
Stefan Lasiewski

0

Đến đây vì những ngày này tôi bắt gặp câu hỏi tương tự trên Ubuntu 18.04 LTS (netstat là phiên bản tương tự netstat 1.42 (2001-04-15)), lạ vẫn không có câu trả lời sau 8 năm. Sau khi duyệt mã nguồn của các công cụ mạng, tôi có thể tìm thấy nó.

Trong mã nguồn netstat:

  1. tất cả các thư mục tiến trình trong / Proc đều được lặp lại, mỗi thư mục fd trong / Proc // fd được kiểm tra để xây dựng bản đồ từ socket inode đến pid / progname.

  2. sau đó / Proc / net / tcp được kiểm tra để lấy thông tin ổ cắm tcp (bằng chức năng tcp_info), bao gồm cả inode ổ cắm.

  3. khi xuất thông tin ổ cắm tcp, pid / progname được truy vấn từ bản đồ ở bước 1 thông qua nút inode. nếu không tìm thấy gì, '-' đầu ra.

Nếu ổ cắm được tạo sau khi bản đồ được xây dựng, pid / progname sẽ không được tìm thấy trong bản đồ.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.