Hmm, I am pretty suspicious of the config file
/etc/apache2/vhosts.d/30_subversion_ssl_vhost.conf
When you remove the '-D SSL' you will cause all parts of the configuration files that are enclosed in ... to be skipped. The default SSL vhost file on my Gentoo box is wrapped in that tag so I wonder if, by removing the '-D SSL', you are preventing the config in 30_subversion_ssl_vhost.conf from being run at all and if that is what is allowing Apache to start.
If you temporarily remove the file 30_subversion_ssl_vhost.conf from /etc/apache2/vhosts.d does Apache run? Are there any other SSL related vhost.conf files in vhosts.d? My reasonably fresh/unused Apache install's vhosts.d directory looks like this:
# pwd && ls
/etc/apache2/vhosts.d
00_default_ssl_vhost.conf 00_default_vhost.conf default_vhost.include
edit 1:
So much for that theory :) I am now wondering if the problem is with the Apache SSL setup itself. I apologize if I am covering ground you have already checked but I am wondering if you could do the following to help verify your Apache install.
On my Apache install with working SSL the use flags are as follows:
# emerge -av apache
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild U ] www-servers/apache-2.2.11-r2 [2.2.11] USE="ssl -debug -doc -ldap (-selinux) -sni -static -suexec -threads" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias -asis -auth_digest -authn_dbd -cern_meta -charset_lite -dbd -dumpio -ident -imagemap -log_forensic -proxy -proxy_ajp -proxy_balancer -proxy_connect -proxy_ftp -proxy_http -substitute -version" APACHE2_MPMS="-event -itk -peruser -prefork -worker" 64 kB
In particular do you have the 'ssl' USE flag set?
Also, could you use equery to verify the integrity of your apache2 install? If you do not have the equery command you can install it by running 'emerge -av gentoolkit'. The following command should verify the integrity of your apache install:
equery check apache
On my server the above command gives the following output:
[ Checking www-servers/apache-2.2.11 ]
!!! /etc/apache2/vhosts.d/00_default_ssl_vhost.conf has wrong mtime (is 1256620928, should be 1246793824)
!!! /etc/apache2/modules.d/00_default_settings.conf has wrong mtime (is 1246796304, should be 1246793824)
!!! /etc/conf.d/apache2 has incorrect md5sum
* 429 out of 432 files good
edit 2:
Well the install looks good to me, so much for theory 2. I am wondering if we can coax Apache into giving some more information on startup. In /etc/conf.d/apache2 if you change your APACHE2_OPTS line from:
APACHE2_OPTS="-D DEFAULT_VHOST -D INFO -D SSL -D SSL_DEFAULT_VHOST -D LANGUAGE"
to
APACHE2_OPTS="-X -e debug -D DEFAULT_VHOST -D INFO -D SSL -D SSL_DEFAULT_VHOST -D LANGUAGE"
and then start Apache (/etc/init.d/apache2 start) the daemon should stay in the foreground (the -X flag) and output debuging messages as it starts (the -e debug option). Maybe this will give a clue as to why it is dying on startup.
I'm not saying this is what's happening but based on my own experience as a CentOS admin, it's most likely runaway apache/php processes taking down the server. I've seen this numerous times on CentOS 5. It's frustrating because there's usually not a trace of what happened in the log files. The machine just grinds to a halt due to physical memory and swap being sucked up by apache/php processes. You would think linux memory management or some daemon would jump in and say "hey stop" but it doesn't. It'll let apache grind your system to a halt.
Having said that, to see what's happening you'll need something that can monitor and log resource usage. I like to use a program called atop. Atop is a lot like the top program but it also takes a snapshot of resource usage at defined intervals. It's pretty simple to install.
wget http://www.atcomputing.nl/Tools/atop/packages/atop-1.23.tar.gz
tar -zxvf atop-1.23.tar.gz
cd atop-1.23 && make install
Open /etc/atop/atop.daily
with a text editor and change INTERVAL=600
to INTERVAL=60
Run the command /etc/atop/atop.daily
from a command prompt to start it. Wait a few minutes and run atop -r /var/log/atop/atop_20091118
with the correct date of course.
Hit the t key to go forward in time and T to go back. Next time your server crashes do this and check the MEM free
and SWP free
lines. If you have memory problems these will be in red. Also look for numerous httpd
lines under CMD
. If apache/php is your problem there'll be a bunch of them.
If this is the case, I recommend looking at you're MaxClients
setting in httpd.conf
. If set too high, apache will gladly eat all of your memory causing your machine to crash. Apache/php can easily eat 40-50MB/process. If you multiply 40mb x MaxClients
you'll get a rough idea of how much memory apache can potentially use. MaxClients
usually defaults to 150 on CentOS so apache can potentially use 6GB of memory by default. This doesn't include memory your system needs for itself and other processes to run. Try setting it to a more realistic value based on the amount of memory you have like 40 if you have 2G of memory and see if that helps. Also if you have KeepAlive On
, set KeepAliveTimeout
to a low number like 2
or 3
.
In my opinion CentOS's apache/php compilation is a real pos that should never have seen the light of day. It's buggy and crash prone. If you run a serious site, I highly recommend compiling your own version of apache/php or even using one of the newer high performance webservers like lighttpd or nginx with fgci php.
Best Answer
First google hit indicates it might be a Debian bug.