Updated Apache released

I'm passing this along to Joe, who maintains the packages.

Virtualmin does have it's own Apache package, due to the specific suexec needs that you mentioned. I wouldn't recommend using a third party Apache package unless it offers the ability to set a custom suexec location (as the Debian/Ubuntu packages are beginning to allow).

I'll roll a new Apache shortly.

We, obviously, don't have anything to do with the kernel, so I won't be doing anything about that one. If you're not seeing it in your available updates, you'll want to check the configuration of yum on your system. kernel may be in the excluded packages list.

Should be fixed now for CentOS 5, 32 and 64 bit. I'm looking into CentOS 4 (and possibly Fedora if we currently have any versions that are still supported by the Fedora project).

Worked good for me too on my test systems - thanks for getting this out!

After updating Apache I'm getting these errors on /var/log/httpd/error_log:

[Sun Sep 05 20:18:03 2010] [warn] (24)Too many open files: mod_fcgid: spawn process /home/website_name/public_html/page_name error [Sun Sep 05 20:18:03 2010] [error] (24)Too many open files: mod_fcgid: couldn't set child process attributes: /etc/httpd/run/mod_fcgid/9508.4606

And on website's error log:

[warn] mod_fcgid: can't apply process slot for /home/website_name/public_html/page_name

I'm also getting:

[error] [client 91.140.83.82] Apache2::Filter::print: (103) Software caused connection abort at /usr/libexec/webmin/virtualmin-google-analytics/Virtualmin/GoogleAnalytics.pm line 86 [Sun Sep 05 18:43:57 2010] [warn] (500)Unknown error 500: mod_fcgid: ap_pass_brigade failed in handle_request function

The problems appear after updating. Most of the time the websites appear OK but sometimes after waiting for a while I'm getting an error 503 "Service Temporarily Unavailable" error page

Howdy -- I've seen cases where Apache manages to hold the logs all open twice. What I would do is:

• Stop Apache, by running: /etc/init.d/httpd stop

• Make sure there aren't any Apache processes running in the background: ps auxw | grep httpd

• If you see any, use the kill command to kill them off

• Start Apache back up with: /etc/init.d/httpd start

After doing all that, do those errors go away?

I rebooted the server two times since the error occurs, but the problems persists. The first one I did it in order to correct the problem as well as in order to pass the new kernel. The problem was there before the reboot, so the kernel should not be responsible for the error.

Once you start getting enough sites setup on your server, it's not uncommon to see "Too many files open" errors in Apache.

To handle that, you can edit /etc/security/limits.conf, and put an entry in there for your webserver... something like this:

apache  hard   nofile   16384

That should raise the limit high enough for Apache to not run into any open file limits for awhile.

Also, make sure that there aren't any restrictions setup in there for your specific users that would cause any one user to run into a max open files problem. That is, if any of your Virtual Server owners were given a max open files limit in that limits.conf file, and it were too low, that could cause what you're seeing too.

I have read the documentation about such problems already (Getting the most out of your server) I'm gonna follow your reccomedations and let you know about the outcome, but it is strange that the problem appeared just after the update.

Howdy -- we'll gladly work with you to figure out what's going awry.

Although what you're using is a version of Apache compiled by Virtualmin, it's really just the CentOS Apache package with suexec changed to use /home rather than /var/www.

So I completely understand that you're seeing this issue now, but we're not making random changes to how Apache works.

Since the "Too many open files" error does come up for a lot of folks (and especially those using the older style writelogs.pl program combined with having a lot of domains on the server), I was hoping to rule out more common causes we've been seeing for that error.

Unfortunatelly the problem persists although I added the following to /etc/security/limits.conf

soft nofile 4096 hard nofile 4096 apache hard nofile 16384

At this file the following commands were already there:

apache hard cpu -1 apache hard nproc -1 apache hard as -1

I also added in /etc/pam.d/login this line:

session required pam_limits.so

and in /etc/rc.d/rc.local added this line:

ulimit -n 4096

I rebooted and after a while the problem appeared again as I show at error_log.

Okay, just to make certain that the file limit is "taking" properly, try editing /etc/init.d/httpd, and add this somewhere near the top (not the first line, but perhaps shortly after that):

ulimit -n 16384

And then restart Apache with:

/etc/init.d/httpd restart

It seems that this command made the trick. I haven't see any annoying message at error_log for the past half an hour. It usually needed 5 minutes to see the messages. Thank you very much for your help. As usual, you prove why Virtualmin should be the number 1 choice.