Hi Everyone,
Thanks for your responses. I wanted to follow up because I *think* I
may have resolved the issue, not 100% sure yet, the problem could still
come back in a few months. However, even though it may have been
resolved, it doesn't really make sense to me as to why this way, and
none of the others. So I wanted to run it by here to see if anyone has
any insight.
The fix was to add a line to the /etc/init.d/httpd script.
ulimit -n 8000
This raises the FD limit for the apache user right before the httpd
process is spawned.
So why didn't all the other ways I tried have any effect? This was
supposed to happen when I raised the limits in the
/etc/security/limits.conf right? Also, when I upped the limits directly
in the proc filesystem.
I'm glad it's fixed, but confused as to why nothing else seemed to work.
Also, the next time my /etc/init.d/httpd file is overwritten by a system
update the fix goes away. So how do I fix this the real way, without
hacking the init script?
Comments, feedback appreciated.
-Nick
Nick Jennings wrote:
Hello,
I'm running a RHEL5 system as a virtual hosting server, (virtualmin).
I've got about 1000~ sites operating at the moment. A few months ago
Apache stopped functioning, a bunch of errors about "Too many open
files". I don't have the exact messages anymore, but I tried a number of
things in the /proc/ filesystem to raise the limit, not of which seemed
to have an effect. Long story short, I ended up changing the apache
config, and putting all 2000+ apache logs into just two files (access &
error logs, which was obviously not the ideal fix, but I was unable to
get any reaction from the system when changing the open file limits. I
left it set at:
# cat /proc/sys/fs/file-max
1334555
Fast forward to this morning, apparently for a brief period of time (not
more than an hour I assume) I had this same issue pop up (first time
since). After doing a bit of searching I (finally) realized perhaps this
was because of my /etc/security/limits.conf settings? (I overlooked this
the first time, at least I think I did).
So I changed the limits for apache:
< @apache - nofile 4096
> @apache soft nofile 8192
> @apache hard nofile 63536
>
>
> Most of the problems had gone away before I made this change to
> limits.conf, however some problems still persist (see below) and I
> haven't changed the apache logs to go back into their separate files
> for each virtual server yet. So for now the system is in a
> semi-operational state, apache works and serves webpages, but doesn't
> function on some things (like bugzilla for instance, and some other
> in-house php webapps), which leaves me uneasy, so I thought I'd write
> to you all here to get your feedback on this issue.
> .
>
>
> 1. I'm still not convinced the changes to limits.conf really worked
> for apache, since i'm still getting these errors. Though now when I su
> to apache it does reflect the new soft limit (but the errors don't go
> away)
> (temporarily gave apache a shell)
> # su - apache
> # ulimit -n
> 8192
>
>
> 2. Every site is not down now (like this morning, or a few months
> ago), but some are, for some example, bugzilla (and some in house
> webapps). Bugzilla is getting an internal server error, and the log
> file says:
>
> [Mon Sep 15 04:55:53 2008] [error] [client 88.146.77.120] (24)Too many
> open files: couldn't set child process attributes:
> /home/sites/secure.cmdwebsites.com/sys/bugzilla/buglist.cgi
> [Mon Sep 15 04:55:53 2008] [error] [client 88.146.77.120] (24)Too many
> open files: couldn't spawn child process:
> /home/sites/secure.cmdwebsites.com/sys/bugzilla/buglist.cgi
>
>
> The internal php webapps get something similar, but in the browser,
> the errors:
>
> ...: failed to open stream: Too many open files in /foo/bar.php on .
> line 815
>
>
> 3. I read here: http://kb.parallels.com/en/260 that I may need to
> recompile Apache and a a few other "system packages". I sure hope
not. > Thoughts?
>
>
>
> Thank you in advance for any help.
> Cheers,
> Nick
>
_______________________________________________
rhelv5-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/rhelv5-list
