Koneksi yatim dalam keadaan CLOSE_WAIT

Saya punya mesin SLES yang mengakumulasikan koneksi TCP dalam keadaan CLOSE_WAIT untuk apa yang tampaknya selamanya. Deskriptor ini akhirnya menyedot semua memori yang tersedia. Saat ini, saya memiliki 3037 dari mereka, tetapi jauh lebih tinggi sebelum reboot cepat baru-baru ini.

Yang menarik adalah bahwa mereka bukan dari koneksi ke port lokal yang saya harapkan memiliki proses mendengarkan. Mereka tidak memiliki PID terkait, dan penghitung waktu mereka tampaknya telah kedaluwarsa.

# netstat -ton | grep CLOSE_WAIT
tcp      176      0 10.0.0.60:54882     10.0.0.12:31663      CLOSE_WAIT  off (0.00/0/0)
tcp       54      0 10.0.0.60:60957     10.0.0.12:4503       CLOSE_WAIT  off (0.00/0/0)
tcp       89      0 10.0.0.60:50959     10.0.0.12:3518       CLOSE_WAIT  off (0.00/0/0)

# netstat -tonp | grep CLOSE_WAIT
tcp       89      0 10.0.0.59:45598     10.0.0.12:1998       CLOSE_WAIT  -                   
tcp       15      0 10.0.0.59:60861     10.0.0.12:1938       CLOSE_WAIT  -                   
tcp        5      0 10.0.0.59:56173     10.0.0.12:1700       CLOSE_WAIT  -     

Saya bukan sabuk hitam ketika datang ke tumpukan TCP, atau jaringan kernel, tetapi konfigurasi TCP tampaknya waras, karena nilai-nilai ini adalah default, per halaman manual:

# cat /proc/sys/net/ipv4/tcp_fin_timeout 
60
# cat /proc/sys/net/ipv4/tcp_keepalive_time 
7200

Jadi apa yang menyebabkannya? Jika penghitung waktu kedaluwarsa, bukankah tumpukan harus secara otomatis menghapus hal ini? Saya secara efektif memberi diri saya DoS jangka panjang karena hal-hal ini menumpuk.

Tidak, tidak ada batas waktu untuk CLOSE_WAIT. Saya pikir itulah yang offdimaksud dalam output Anda.

Untuk keluar CLOSE_WAIT, aplikasi harus menutup soket secara eksplisit (atau keluar).

Lihat Cara memecahkan CLOSE_WAIT .

Jika netstatditampilkan -di kolom proses:

• apakah Anda menjalankan dengan hak dan kemampuan yang sesuai (misalnya sebagai root)?
• mereka bisa berupa proses kernel (mis. nfsd)

CLOSE_WAITmenunjukkan bahwa klien sedang menutup koneksi tetapi aplikasi belum menutupnya, atau klien tidak. Anda harus mengidentifikasi program atau program mana yang mengalami masalah ini. Coba gunakan netstat -tonp 2>&1 | grep CLOSEuntuk menentukan program mana yang menahan koneksi.

Jika tidak ada program yang terdaftar, maka layanan disediakan oleh kernel. Ini kemungkinan layanan RPC seperti nfsatau rpc.lockd. Mendengarkan layanan kernel dapat didaftar dengan netstat -lntp 2>&1 | grep -- -.

Kecuali jika layanan RPC telah terikat ke port tetap, mereka akan mengikat port sesaat ketika koneksi Anda terlihat muncul. Anda mungkin juga ingin memeriksa proses dan pemasangan di server lain.

Anda dapat mengikat layanan NFS Anda ke port tetap dengan melakukan hal berikut:

1. Pilih empat port yang tidak digunakan untuk NFS (32763-32766 digunakan di sini)
2. Tambahkan port tetap untuk NFS ke /etc/services

   siaran rpc.statd-bc 32763 / udp # RCP statd
   rpc.statd-bc 32763 / tcp
   rpc.statd 32764 / udp # RCP statd dengarkan
   rpc.statd 32764 / tcp
   rpc.mountd 32765 / udp # RPC mountd
   rpc.mountd 32765 / tcp
   rpc.lockd 32766 / udp # RPC lockd / nlockmgr
   rpc.lockd 32766 / tcp

3. Konfigurasikan statd untuk menggunakan opsi --port 32763 --outgoing-port 32764
4. Konfigurasikan rpcmountd untuk menggunakan opsi --port 32765
5. Matikan dan mulai ulang layanan NFS dan RPC.