Newsgroup: it.comp.os.linux.sys
Titolo: file-nr

Tra un po mi si chiude la vena....
Stando alla documentazione del kernel, in file-nr troviamo,
nell'ordine: il numero di file descriptor aperti, il numero di quelli
non ancora utilizzati, il numero di file descriptor massimi
allocabili.
In teoria, sottraendo dal numero massimo il numero di descriptor
aperti (quindi colonna3 - colonna1) dovrei ottenere la colonna2.
Come cappero è possibile questo:
# cat file-nr
3392	0	400000
Avendo 400k file descriptor allocabili, ed avendone solo 3392
allocati, chi diavolo mi ha fregato gli altri 396608.
Ovviamente apache si arrabbia e smette di funzionare loggando una
sfilza di errori tipo: "not enough free resources".
Anche qui, le impostazioni sembrano corrette:
# ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
file size               (blocks, -f) unlimited
pending signals                 (-i) 16383
max locked memory       (kbytes, -l) 32
max memory size         (kbytes, -m) unlimited
open files                      (-n) 400000
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) 16383
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited
# cat inode-state
516469	107478	0	0	0	0	0
Chi mi sta rubando i descriptor? I folletti?

 Chi mi sta rubando i descriptor? I folletti?
hai piu' di 1024 fd aperti.

 hai piu' di 1024 fd aperti.
Si lo so, ho incrementato il limite apposta.
Ma a quanto pare si blocca a poco più di 3000 fd anzichè arrivare al
mio limite...

 
/usr/src/linux/Documentation/filesystems/proc.txt
Historically, the three values in file-nr denoted the number of allocated 
file handles,  the number of  allocated but  unused file  handles, and  the 
maximum number of file handles. Linux 2.6 always  reports 0 as the number of 
free file handles -- this  is not an error,  it just means that the  number 
of allocated file handles exactly matches the number of used file handles.
forse il tuo problema è che l'utente che esegue apache non ha gli stessi 
limiti che ha root.

 limiti che ha root.
# su apache -c "ulimit -n"
1024
vacca miseria!
Ieri era a 400k.
Per caso c'è qualcosa che imposta automaticamente a 1024 i file
descriptor dopo tot tempo?
Ieri sera era a 400k e non ho nessun cron attivo, ho controllato ora.

 limiti che ha root.
Però come faccio a far cambiare i limiti all'utente di apache?
Non può eseguire ulimit -n

 Banalizzimo: farai mica girare apache come root?
No, gira come apache.

 quelli interni di apache
E non c'è l'ho. E' la prima cosa che ho verificato.
E' una slackware.

 1024
Ti consiglio di dare una lettura al thread aperto da me su Apache e logs 
della settimana scorsa.
-- 
Vide

 della settimana scorsa.
Ho letto e non ci cavo ugualmente le zampe.
Attualmente non posso ne fare un unico log, ne loggare in remoto.
Ho 450 virtualhost configurati, ma su un server ne ho oltre 1500 e non
ho mai avuto problemi.
Qualche idea su come bypassare questo limite?

 Qualche idea su come bypassare questo limite?
Dunque, dovrei essere riuscito ad aumentare i limiti a 65535
modificato
lo script di avvio di apache (che di default alza il soft limit
all'hard limit).
Ho messo un semplice ulimti -H -n > /tmp/ulimit ed /tmp/ulimit
contiene 65535 per cui
il softlimit impostato alla riga sotto con ulimit -S -n $(ulimit -H -
n) dovrebbe funzionare.
Come faccio a controllare quale è il limite di apache? Ovviamente se
mi collego in ssh mi viene
forkata una nuova shell che ha come limite 1024, come faccio a sapere
apache con che valore gira?