it-swarm-id.com

Koneksi yatim di negara CLOSE_WAIT

Saya punya mesin SLES yang mengakumulasi TCP koneksi dalam keadaan CLOSE_WAIT untuk apa yang tampaknya selamanya. Penjelas ini akhirnya menyedot semua memori yang tersedia. Saat ini, saya punya 3037 dari mereka, tapi itu jauh lebih tinggi sebelum buru-buru reboot 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 timer 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 standar , 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 menghapus hal ini secara otomatis? Saya secara efektif memberi diri saya DoS jangka panjang karena hal-hal ini menumpuk.

30
pboin

Tidak, tidak ada batas waktu untuk CLOSE_WAIT. Saya pikir itulah arti off dalam output Anda.

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

Lihat Cara memecahkan CLOSE_WAIT .

Jika netstat ditampilkan - di kolom proses:

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

CLOSE_WAIT menunjukkan 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 CLOSE

untuk menentukan program mana yang menahan koneksi.

Jika tidak ada program yang terdaftar, maka layanan disediakan oleh kernel. Ini kemungkinan layanan RPC seperti nfs atau 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 muncul untuk ditampilkan. Anda mungkin juga ingin memeriksa proses dan pemasangan di server lain.

Anda mungkin 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
    rpc.statd-bc 32763/udp # RCP statd broadcast 
     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.
10
BillThor