Apache dies 2nd night in a row

The site went down again last night even though I added "sleep 2" to the httpd script. The only thing that's scheduled to run in crontab the time Aapache dies is:

30 0 * * * root echo 'action=tally&value=all' >> /usr/local/directadmin/data/tas
k.queue

I'm using Freebsd 4.9
 
Ok.. so here's what we know.

Nobody on the server, so that rules out log rotation because logs are rotated based on size.
Also rules out bad cgi scripts, as there are none.

Found this:
http://archive.apache.org/gnats/6627

So we need to find out what would prevent an apache child from exiting. That thread mentioned an NFS, but I'm not you use one.

How about check the /var/log/directadmin/errortaskq.log and system.log for apache restarts around that time. See if the restart is failing.

A few other things to try is to put a long pause *after* the start/stop .. so that there is no downtime, but prevents the taskq from checking to see if it worked for a few seconds longer after is did restart. If the check is done too soon, apache might not be running yet..

I'm starting to run out of ideas for this..

John
 
In both of the log files you mention, I have this same basic thing over and over

2004:04:04-10:06:06: httpd restarted
2004:04:04-10:07:02: httpd started
2004:04:04-10:07:06: httpd restarted
2004:04:04-10:08:00: httpd started
2004:04:04-10:08:05: httpd restarted
2004:04:04-10:09:01: httpd started
2004:04:04-10:09:05: httpd restarted
2004:04:04-10:10:01: httpd started
2004:04:04-10:10:05: httpd restarted
 
After doing some searches on google I think I've narrowed it down to mod_perl. I'll try some tricks tonight and report back on what I find.
 
Any special way in how you rebuilt it? Can you say how?

I have found issues like this in the past with non-DA freebsd systems where when I add a port or change PHP in some way, the only real way to get Apache working again is a make deinstall / make reinstall.
 
Here is what I did.

cd /usr/local/directadmin/customapache
./build mod_perl


If that doesn't work then just do the following:

cd /usr/local/directadmin/customapache
./build clean
./build update
./build all

I think when perl got updated somehow mod_perl needed to be updated to recognize the new version of perl as well.

Kevin
 
Sorry to ask this stupid question in this thread, but does running the update all erase any data files associated with the programs that are being upgraded?
 
www6# ./build mod_perl
Found /usr/local/directadmin/customapache/mod_perl-1.0-current.tar.gz
Extracting ...
Done.
Configuring mod_perl-1.27...
perl: not found
Done. Making mod_perl-1.27...
Trying to make mod_perl...
make: no target to make.

*** The make has failed, do you want to try to make again? (y,n):


Any ideas?
 
Hello,

does running the update all erase any data files associated with the programs that are being upgraded?
Click to expand...
No, it doesn't overwrite anything already exiting other than the build script and the README. If you want to revert to the default files, just delete them and then update again.

perl: not found
Click to expand...
What happens when you type:
which perl

John
 
1. So if I do an upgrade of MySQL, the database will not be wiped out?

2. www6# which perl
perl: Command not found.

www6# uname -a
FreeBSD 5.1-RELEASE FreeBSD 5.1-RELEASE #0: Thu Jun 5 02:55:42 GMT 2003 [email protected]:/usr/obj/usr/src/sys/GENERIC i386
 
uninstalled perl b/c my server was not recognizing it even though it claimed to be installed

reinstalled perl

updated everything through customapache

everything works now and no more nightly crashing
 
Same problem, same solution

Thank-you for having this thread. We, too, spent a week tracking it down before I thought to search DirectAdmin support. I have not yet tested it overnight, it has survived a domain addition.

I have one more datum which I'm not completely confident in and that is that when Apache restarted itself reliably (until the upgrades), @INC was looking for things in /usr/local/lib/perl5/5.8.5, afterwards, it was looking in 5.8.0. This was problematic because the whole mach directory in which Cwd.pm is located does not exist in 5.8.0. I suspect that somewhere out there in port land, there is a port or package which redefines @INC to an earlier version.

It would be nice to track this down as it forms a very bad first impression of DirectAdmin.
 
You must log in or register to reply here.
Back
Top