Newsgroup: it.comp.os.linux.sys
Titolo: CLOSA_WHAT?

Negli ultimi giorni abbiamo avuto alcuni problemi con una macchina di
produzione che ospita alcuni siti web (una decina): ogni tanto apache si
inchioda e non accetta piu' richieste di connessione.
Ho trovato una sfilza di connessioni in stato CLOSE_WAIT legate a processi
di apache, e come palliativo ho creato uno script che terminasse i processi
figli con connessioni in CLOSE_WAIT per oltre cinque secondi.
Oggi la macchina si e' bloccata di nuovo, ho verificato ed ecco il
risultato:
# netstat -anpd|grep http
tcp        0      0 
0.0.0.0:80
              0.0.0.0:*               LISTEN
23583/httpd
tcp        0      0 
0.0.0.0:443
             0.0.0.0:*               LISTEN
23583/httpd
tcp        0   5274 194.185.xx.yyz:80       
80.105.18.60:50856
FIN_WAIT1   32738/httpd
Ad occhio parrebbe che sia tutto a posto... E invece:
# netstat -anpd|grep CLOSE_WA
tcp      124      0 194.185.xx.yyy:80       
194.185.30.21:2722
CLOSE_WAIT  -
tcp      166      0 194.185.xx.yya:80       
211.157.36.3:4434
CLOSE_WAIT  -
tcp      106      0 194.185.xx.yyz:80       
194.185.30.21:2731
CLOSE_WAIT  -
tcp      564      0 194.185.xx.yyw:80       
213.156.52.102:12365
CLOSE_WAIT  -
tcp      352      0 194.185.xx.yyz:80       
80.58.32.107:57480
CLOSE_WAIT  -
tcp        1      0 194.185.xx.yyw:80       
62.11.23.19:1167
CLOSE_WAIT  -
tcp      509      0 194.185.xx.yyz:80       
62.211.35.125:2839
CLOSE_WAIT  -
tcp      106      0 194.185.xx.yyz:80       
194.185.30.21:2696
CLOSE_WAIT  -
tcp      468      0 194.185.xx.yyz:80       
140.105.48.199:46459
CLOSE_WAIT  -
tcp      124      0 194.185.xx.yyy:80       
217.221.57.3:1813
CLOSE_WAIT  -
tcp      537      0 194.185.xx.yyz:80       
62.211.35.125:2230
CLOSE_WAIT  -
tcp      124      0 194.185.xx.yyy:80       
194.185.30.21:2694
CLOSE_WAIT  -
tcp      124      0 194.185.xx.yyy:80       
217.221.57.3:1811
CLOSE_WAIT  -
tcp      437      0 194.185.xx.yyz:80       
62.211.35.125:2961
      CLOSE_WA
IT  -
tcp      106      0 194.185.xx.yyz:80       
194.185.30.21:2670
CLOSE_WAIT  -
tcp      352      0 194.185.xx.yyz:80       
80.58.32.107:42284
CLOSE_WAIT  -
tcp      410      0 194.185.xx.yyz:80       
62.211.35.125:2960
CLOSE_WAIT  -
tcp      124      0 194.185.xx.yyy:80       
194.185.30.21:2663
CLOSE_WAIT  -
tcp      408      0 194.185.xx.yyz:80       
213.140.6.125:27977
CLOSE_WAIT  -
tcp      327      0 194.185.xx.yyz:80       
213.140.6.125:37128
CLOSE_WAIT  -
tcp      106      0 194.185.xx.yyz:80       
217.221.57.3:1816
CLOSE_WAIT  -
tcp      177      0 194.185.xx.yyz:80       
62.211.35.125:2226
CLOSE_WAIT  -
tcp      222      0 194.185.xx.yyw:80       
66.249.64.195:42030
CLOSE_WAIT  -
tcp      393      0 194.185.xx.yx:80        
193.147.81.70:2177
CLOSE_WAIT  -
tcp      249      0 194.185.xx.yyz:80       
213.140.6.125:32645
CLOSE_WAIT  -
tcp      424      0 194.185.xx.yx:80        
193.147.81.70:2178
CLOSE_WAIT  -
tcp      439      0 194.185.xx.yyz:80       
62.211.35.125:2559
CLOSE_WAIT  -
tcp      106      0 194.185.xx.yyz:80       
217.221.57.3:1812
CLOSE_WAIT  -
tcp      508      0 194.185.xx.yyz:80       
62.211.35.125:2526
CLOSE_WAIT  -
tcp      508      0 194.185.xx.yyz:80       
62.211.35.125:2558
CLOSE_WAIT  -
tcp      408      0 194.185.xx.yyz:80       
62.211.35.125:2329
CLOSE_WAIT  -
tcp      417      0 194.185.xx.yyz:80       
62.211.35.125:2393
CLOSE_WAIT  -
tcp      140      0 194.185.xx.yyb:80       
195.210.89.28:41988
CLOSE_WAIT  -
tcp      173      0 194.185.xx.yyy:80       
211.157.36.9:3404
CLOSE_WAIT  -
tcp      222      0 194.185.xx.yyw:80       
66.249.64.37:46227
CLOSE_WAIT  -
tcp      408      0 194.185.xx.yyz:80       
81.112.68.234:25623
CLOSE_WAIT  -
tcp      430      0 194.185.xx.yyz:80       
62.211.35.125:2395
CLOSE_WAIT  -
tcp      424      0 194.185.xx.yyz:80       
80.58.32.107:52455
CLOSE_WAIT  -
tcp      417      0 194.185.xx.yyz:80       
62.211.35.125:2299
CLOSE_WAIT  -
tcp      430      0 194.185.xx.yyz:80       
62.211.35.125:2394
CLOSE_WAIT  -
tcp      542      0 194.185.xx.yx:80        
80.58.32.42:50515
CLOSE_WAIT  -
tcp      347      0 194.185.xx.yyz:80       
62.211.35.125:2309
CLOSE_WAIT  -
tcp      762      0 194.185.xx.yx:80        
193.147.81.70:2168
CLOSE_WAIT  -
tcp      906      0 194.185.xx.yx:80        
193.147.81.70:2169
CLOSE_WAIT  -
tcp      542      0 194.185.xx.yx:80        
80.58.32.42:35790
CLOSE_WAIT  -
tcp      124      0 194.185.xx.yyy:80       
217.221.57.3:1797
CLOSE_WAIT  -
tcp      426      0 194.185.xx.yyz:80       
80.58.32.107:42330
CLOSE_WAIT  -
tcp      424      0 194.185.xx.yyz:80       
80.58.32.107:38298
CLOSE_WAIT  -
tcp      468      0 194.185.xx.yyz:80       
140.105.48.199:48842
CLOSE_WAIT  -
tcp      124      0 194.185.xx.yyy:80       
217.221.57.3:1827
CLOSE_WAIT  -
tcp      269      0 194.185.xx.yyz:80       
62.211.35.125:2304
CLOSE_WAIT  -
tcp      177      0 194.185.xx.yyz:80       
62.211.35.125:2211
CLOSE_WAIT  -
tcp      106      0 194.185.xx.yyz:80       
217.221.57.3:1800
CLOSE_WAIT  -
tcp      564      0 194.185.xx.yyw:80       
213.156.52.102:16699
CLOSE_WAIT  -
tcp      174      0 194.185.xx.yyc:80       
211.157.36.5:1651
CLOSE_WAIT  -
tcp      439      0 194.185.xx.yyz:80       
62.211.35.125:2253
CLOSE_WAIT  -
tcp        1      0 
127.0.0.1:80
 
127.0.0.1:34521
CLOSE_WAIT  -
tcp      426      0 194.185.xx.yyz:80       
80.58.32.107:52240
CLOSE_WAIT  -
tcp      599      0 194.185.xx.yyz:80       
140.105.48.199:49856
CLOSE_WAIT  -
tcp      106      0 194.185.xx.yyz:80       
217.221.57.3:1830
CLOSE_WAIT  -
tcp      537      0 194.185.xx.yyz:80       
62.211.35.125:2252
CLOSE_WAIT  -
tcp      509      0 194.185.xx.yyz:80       
62.211.35.125:2540
CLOSE_WAIT  -
tcp      412      0 194.185.xx.yyz:80       
62.211.35.125:2959
CLOSE_WAIT  -
tcp      337      0 194.185.xx.yyz:80       
62.211.35.125:2862
CLOSE_WAIT  -
tcp      548      0 194.185.xx.yyz:80       
80.58.32.107:43986
CLOSE_WAIT  -
tcp      407      0 194.185.xx.yyz:80       
213.140.6.125:28307
CLOSE_WAIT  -
tcp      408      0 194.185.xx.yyz:80       
213.140.6.125:28179
CLOSE_WAIT  -
tcp      426      0 194.185.xx.yyz:80       
80.58.32.107:38133
CLOSE_WAIT  -
tcp        1      0 194.185.xx.yyw:80       
62.11.23.19:1168
CLOSE_WAIT  -
tcp      508      0 194.185.xx.yyz:80       
62.211.35.125:2664
CLOSE_WAIT  -
tcp      508      0 194.185.xx.yyz:80       
62.211.35.125:2408
CLOSE_WAIT  -
tcp      222      0 194.185.xx.yyw:80       
66.249.64.49:47060
CLOSE_WAIT  -
tcp      547      0 194.185.xx.yx:80        
193.147.81.70:2166
CLOSE_WAIT  -
tcp      337      0 194.185.xx.yyz:80       
62.211.35.125:2859
CLOSE_WAIT  -
tcp      537      0 194.185.xx.yyz:80       
62.211.35.125:2251
CLOSE_WAIT  -
tcp      508      0 194.185.xx.yyz:80       
62.211.35.125:2539
CLOSE_WAIT  -
tcp      547      0 194.185.xx.yx:80        
193.147.81.70:2167
CLOSE_WAIT  -
tcp      426      0 194.185.xx.yyz:80       
80.58.32.107:57558
CLOSE_WAIT  -
tcp      177      0 194.185.xx.yyz:80       
62.211.35.125:2218
CLOSE_WAIT  -
tcp      508      0 194.185.xx.yyz:80       
62.211.35.125:2538
CLOSE_WAIT  -
[root@lweb01 /home/webtrend]# apachectl stop
[root@lweb01 /home/webtrend]# netstat -anpd|grep CLOSE_WA
[root@lweb01 /home/webtrend]# apachectl start
All'inizio avevo pensato ad un DoS, ma
127.0.0.1:80
 
127.0.0.1:34521
Sembra smentirmi...
Idee?
Ciaotutti,
*
-- 
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

 Idee?
Mi sembra strano che la macchina non accetti piu' connessioni del tutto,
a meno che tu non intenda "Apache non accetta piu' connessioni",
in questo caso forse potresti aumentare il numero di connessioni
disponibili e/o modificare il numero di connessioni per ogni child.
Controlla sul log di apache se ci sono degli errori, hai modificato
qualche cosa ultimamente? Nuovi moduli di apache? aggiornato qualche
modulo extra? E' solo apache o usi qualche application server?
Davide
-- 
Windows: The answer to a question nobody has ever asked. 


Il problema si e' presentato un sabato... Che io sappia nessuno ha fatto
alcuna modifica sulla macchina da mesi.
Niente application server,
Nei log trovo cose tipo
[Tue Nov 09 10:35:31 2004] [warn] child process 20171 still did not exit, se
nding a SIGTERM
quando certo di riavviare apache; in piu' ho trovato questo:
TutorialConfig is successfully loaded!
We just created the variable...
and now it's a TutorialConfig object!
e questo:
[Tue Nov 09 11:20:05 2004] [error] server reached MaxClients setting,
consider raising the MaxClients setting
Ma questo credo dipenda dal fatto che ci sono 9000 child in attesa di
chiudere la connessione.


 and now it's a TutorialConfig object!
TutorialConfig e' un modulo di perl. Non e' che carichi qualche cosa
tipo mod_perl?
Comunque, di problemi di child "appesi" ne ho visti tanti, ma in genere
coinvolgono _sempre_ un qualche modulo aggiuntivo, sia esso PHP o
un qualche connector per ApplicationServer.
Verifica _bene_ quali moduli carica il tuo Apache.
Davide
-- 
In 1968 it took the computing power of 2 C-64's to fly a rocket to the moon.
Now, in 1998 it takes the Power of a Pentium 200 to run Microsoft Windows 95.
Something must have gone wrong.


Aeh, la lista e' lunga...
LoadModule access_module modules/mod_access.so
LoadModule auth_module modules/mod_auth.so
LoadModule auth_anon_module modules/mod_auth_anon.so
LoadModule auth_dbm_module modules/mod_auth_dbm.so
LoadModule auth_digest_module modules/mod_auth_digest.so
LoadModule include_module modules/mod_include.so
LoadModule log_config_module modules/mod_log_config.so
LoadModule env_module modules/mod_env.so
LoadModule mime_magic_module modules/mod_mime_magic.so
LoadModule cern_meta_module modules/mod_cern_meta.so
LoadModule expires_module modules/mod_expires.so
LoadModule headers_module modules/mod_headers.so
LoadModule usertrack_module modules/mod_usertrack.so
LoadModule unique_id_module modules/mod_unique_id.so
LoadModule setenvif_module modules/mod_setenvif.so
LoadModule mime_module modules/mod_mime.so
LoadModule dav_module modules/mod_dav.so
LoadModule status_module modules/mod_status.so
LoadModule autoindex_module modules/mod_autoindex.so
LoadModule asis_module modules/mod_asis.so
LoadModule info_module modules/mod_info.so
LoadModule cgi_module modules/mod_cgi.so
LoadModule dav_fs_module modules/mod_dav_fs.so
LoadModule vhost_alias_module modules/mod_vhost_alias.so
LoadModule negotiation_module modules/mod_negotiation.so
LoadModule dir_module modules/mod_dir.so
LoadModule imap_module modules/mod_imap.so
LoadModule actions_module modules/mod_actions.so
LoadModule speling_module modules/mod_speling.so
LoadModule userdir_module modules/mod_userdir.so
LoadModule alias_module modules/mod_alias.so
LoadModule rewrite_module modules/mod_rewrite.so
LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_ftp_module modules/mod_proxy_ftp.so
LoadModule proxy_http_module modules/mod_proxy_http.so
LoadModule proxy_connect_module modules/mod_proxy_connect.so
Parte di questi sono probabilmente inutili... Pero' la macchina di backup ha
lo stesso file di configurazione e funziona senza problemi.
Inoltre non capisco perche' i problemi siano iniziati solo di recente...


 Inoltre non capisco perche' i problemi siano iniziati solo di recente...
Per questo ti ho chiesto se e' stato fatto qualche upgrade.
Davide
-- 
Debating unix flavors in the context of anything Microsoft is like talking
about which ice cream flavor tastes least like sawdust with turpentine
sauce.  --void

 Per questo ti ho chiesto se e' stato fatto qualche upgrade.
Io provvederei anche a controllare qualcosina con chkrootkit.
Diverse macchine bucate con SuckIt hanno questo problema.
Che versione di kernel utilizzi ?
Max

 Che versione di kernel utilizzi ?
# cat /proc/version
Linux version 2.4.20-18.9 (
bhco...@porky.devel.redhat.com
) (gcc version
3.2.2 20030222 (Red Hat Linux 3.2.2-5)) #1 Thu May 29 07:08:16 EDT 2003
Comunque, per non saper ne' leggere ne' scrivere ho gia' proposto un bel
cambio radicale verso Debian, che mi risolve anche il problema degli
aggiornamenti...
Solo che non mi fido a usare sarge per macchine di produzione, e woody ha
parecchie cose (apache, mysql, php...) che sono versioni (e parlo di major
number) indietro rispetto a quelle che che ci servono...


 number) indietro rispetto a quelle che che ci servono...
Ormai era stato annunciato per settembre il rilascio di sarge come ramo
"stable" quindi se non hai premura io penso che prima dell'anno nuovo
sarge verrà rilasciata come versione stabile.
Anzi, stabile gia lo è tutt'ora e te lo può testimoniare il lavoro
febbrile di bug-fixing che viene svolto sui pacchetti.
Quindi se pianifichi la migrazione del/dei server verso sarge non fai
affatto male, anche perchè sarebbe poi piu problematico fare l'upgrade da
woody a sarge (IMHO).
ciao fab

 sarge verrà rilasciata come versione stabile.
Ecco, ora che lo hai detto verrà rilasciata nel 2010... ;)
ciao
Luca

 febbrile di bug-fixing che viene svolto sui pacchetti.
E il fatto che apache2-common non mi si installa su un sistema pulito come lo
spiego al capo, che vorrebbe che mrettessi fedora?
Ma soprattutto, come lo convinco che fedora non e' la soluzione?
