Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
Greetings folks. I'm fairly new to the area, and am looking forward to getting involved with the local lugs in the area here, as they have always been a source of fun and learning elsewhere in my past. :o) That being said, I really hate that my first post to this list has to be a question, but I've been up all night fighting with a particular problem and I've reached the end of my rope....am hoping someone here can loan me a few extra feet (and not to hang myself with :o) ) I've got a box that I do admin work on...this box is currently pushing the 300 domain mark. And lo and behold, if we've not run out of file descriptors and had apache puke in a major way. No biggie, I knew there were ways to push the number of descriptors higher so I began like I always do, with a web search. Everything from "echo "4096" > /proc/sys/fs/file-max" right down to actually editing limits.h and fs.h in /usr/src/linux/include/linux and recompiling the kernel (per some info I found on http://www.bb-zone.com/Proc/). Nothing seems to change the hard set 1024 descriptors per process number... So currently, I have to reboot the box, log in, do a ulimit -n 4096, THEN start apache, and everything is fine. Am I just missing something really obvious here? Is there a way to change permanently the hard set number of file descriptors available to a process? Anyone out there done this? Faced this problem? Made it better? Any advice, words of wisdom, or lots of coffee accepted. Looking forward to meeting you folks, Alex ps: redhat 6.2, kernel 2.2.14. output of lsof shows apache pushing roughly 1045, which is how I'm pretty certain despite everything I've done that there is still a 1024 set somewhere that I've not managed to change yet. - Subcription/unsubscription/info requests: send e-mail with "subscribe", "unsubscribe", or "info" on the first line of the message body to discuss-request at blu.org (Subject line is ignored).
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |