apache getting stuck

John: For the next custombuilder release, please, build in a check for FreeBSD or RH. I removed the added code as you recommended (without further editing other files). And the load now goes upto 1.90 as max and at this moment it's stable at 0.80.
Click to expand...
To which check are you referring? and you're referring to removing the ErrorLog line?

When the load is really high, whats eating the resoureces? (use 'top')

John
 
DirectAdmin Support said:
To which check are you referring? and you're referring to removing the ErrorLog line?

When the load is really high, whats eating the resoureces? (use 'top')

John
Click to expand...

I was wondering, I just finished the nightly tally 'sim', load went up to 8.84 but while I'm typing this it's back to 2.37. (MRTG is messing it up at the moment, it was 0.32 first)
No, I am referring to the /var/log/httpd/access log file.

Can you add a check if the OS is FreeBSD or Linux to see what configure.apache_ssl is needed ?
When i removed the first lines it worked way better, load is lower now.

While the load was high, httpd and mysqld were using 99% CPU time (both) in top. Restarting the service fixed it for a few minutes, but that isn't enough for a production server... ;)
This was caused by a few problems:
* MySQLD was wrong, strace pointed to a bug or something not working so I updated from 4.0.14 to 4.0.17
* httpd was using 99% CPU, but the /server-status indicated that it was using less.
* Perhaps some memory issues, the swap partition isn't working (was wondering if you have time to update the install instructions of DA for RH to reflect a 2x memory SWAP partition instead of a /dev/shm partition, since some people really MAKE that partition (ext3) and fixing that really isn't very much fun...)
But the system has 1 GB ram, so i'd figure everything would run smoothly...
 
Hi,

The tally is killing Apache nightly for me too with a signal 11 - do DA have a solution for this as yet?

The system RAM is not faulty, we had it tested two weeks ago with memtest.

Using FreeBSD 5.3 with Apache 1.3.33.

Many thanks,
Matt
 
Same problem here, da running on ubuntu dapper, once in a few weeks apache doesnt restart like it should. It sais port 80 in use, and when I check via ps -auwwx I indeed see 1 /usr/sbin/httpd process running. After killing that (-9) I can start apache again.

Anyone have a solution for this problem?
 
And it happened again last night:

[Thu Feb 22 00:11:03 2007] [warn] Init: You should not use name-based virtual hosts in conjunction with SSL!!
[Thu Feb 22 00:11:03 2007] [notice] Apache/2.2.4 (Unix) mod_ssl/2.2.4 OpenSSL/0.9.8a PHP/4.4.4 configured -- resuming normal operations
[Thu Feb 22 00:13:02 2007] [notice] caught SIGTERM, shutting down
 
I have been having the same issue on 2 servers now for the past 2 days since ive upgraded to apache2 and php5.

I have tried editing the virtual_host*.conf templates, and commenting out the "ErrorLog" lines.

This had not worked.

Currently have a crontab set for a temporary work around like Wunk.

I have been told that the Tally can be shut down. If this is so, how would I go about doing this?
 
httpd cpu hog

I have tried everything I have come across on here to get this issue fixed.

Some people say it has something to do with apache getting stuck during the log rotation, some people say it has to do with exim. I have tried commenting out the "ErrorLog" lines in virtual_host*.conf files to rebuilding apache and php right up to shutting down exim just for giggles.

All with the same issue.

Shortly after you do (echo "action=tally&value=all" >> /usr/local/directadmin/data/task.queue) httpd goes bonkers and hoofs it up to 99% cpu.

The only thing that has not been done is to shut down the tallying.

I am at a loss here. Has anyone come up with some solution/fix to this issue besides setting a crontab to kill and reload apache? :confused:
 
Ok, I have found what I believe at the moment is a work around and not a fix yet. If you are still having issues with httpd spiking after the nightly tally, try the following:

Try changing the apache boot script to do graceful restarts.
Edit /usr/local/etc/rc.d/httpd

Find this chunk of code:

restart)
stop
waitforexit "httpd" 20
start
;;

change it to look like:

restart)
kill -USR1 `cat $PIDFILE`
;;


However, this isn't a full restart. So test out creating a new user and see how apache behaves with this version of the script.
It may need the previous method for new users, new domains, ssl certificate changes, account suspension.. but graceful for other cases.

Like all changes you make to your system, always make a back up file so PLEASE PLEASE do - cp httpd httpd.bak and then edit the httpd boot script.

Hope this helps.
 
I need 1 user who is having problems with apache2, to test a "patch" for this. If there are any - please contact me.
 
I have been having this problem as well. I don't think it is the tally's, because I will have Apache 2 crash at ~4pm, sometimes at ~7am, and even ~3am. There doesn't seem to be a set minute or any crons that run around the same times. And sometimes it will go days or weeks without a problem, but sometimes it is everyday. I had made crons to restart Apache every hour at 38 minutes after the hour, however, that didn't really help the situation.

DA Service monitor will say that Apache's process has been stopped, however, there is usually a process open still for Apache. Sometimes it will be taking 99% of the CPU cycles, sometimes it will be taking 0%. I think when I catch it right after crash it will be taking the 99%. I didn't see anything in the logs to suggest much of anything. I'll try to catch it again.

Recompiles have not worked.
 
RH 9 was EOL'ed a long time ago. Surely, you are aware of this? Anyone running RH 9 and version lower than this can expect to get rooted, no matter what you do as far as security is concerned. I guarantee it. Its only a matter of time. It doesnt take much to upgrade the box to at least CentOS. There really is no excuse and the best part of it is, these types of problems will go away.
 
Last edited:
pucky said:
RH 9 was EOL'ed a long time ago. Surely, you are aware of this? Anyone running RH 9 and version lower than this can expect to get rooted, no matter what you do as far as security is concerned. I guarantee it. Its only a matter of time. It doesnt take much to upgrade the box to at least CentOS. There really is no excuse and the best part of it is, these types of problems will go away.
Click to expand...

I am using Fedora Core 6 on this box. I'm not sure how having RH 9 will up your chances of being rooted as long as you keep some of the obvious stuff with up to date compiles and use propper security policies...but that is another topic.
 
Wunk said:
We have a DA machine (Redhat 9, 1 GB mem, Dell 650) which regularly has apache crashing out..


The error log says:
[Mon Jan 26 20:37:02 2004] [warn] child process 11927 still did not exit, sending a SIGTERM
[Mon Jan 26 20:37:02 2004] [warn] child process 11972 still did not exit, sending a SIGTERM
[Mon Jan 26 20:37:02 2004] [warn] child process 11995 still did not exit, sending a SIGTERM
[Mon Jan 26 20:37:07 2004] [error] Cannot remove module mod_frontpage.c: not found in module list
[Mon Jan 26 20:37:09 2004] [warn] module perl_module is already loaded, skipping
[Mon Jan 26 20:37:10 2004] [crit] (98)Address already in use: make_sock: could not bind to port 8090


I can't find out what causes this, but it happens quite a lot.., and customers are complaining.., all that helps is killing -9 all running httpd processes and restarting the service..

Any suggestions on what could cause this or even better: a solution ?
Click to expand...

Ye, id like to know whats going on with this. We have had this happen at least 3 times this evening exactly the same error. Since our site is mysql driven we get a Mysql error back as well.

[Sat Apr 28 00:32:02 2007] [warn] child process 31824 still did not exit, sending a SIGTERM
[Sat Apr 28 00:32:02 2007] [warn] child process 31825 still did not exit, sending a SIGTERM
[Sat Apr 28 00:32:02 2007] [warn] child process 31826 still did not exit, sending a SIGTERM
[Sat Apr 28 00:32:02 2007] [warn] child process 31827 still did not exit, sending a SIGTERM
[Sat Apr 28 00:32:02 2007] [warn] child process 31828 still did not exit, sending a SIGTERM
[Sat Apr 28 00:32:02 2007] [warn] child process 31829 still did not exit, sending a SIGTERM
[Sat Apr 28 00:32:02 2007] [warn] child process 31830 still did not exit, sending a SIGTERM
[Sat Apr 28 00:32:02 2007] [warn] child process 31831 still did not exit, sending a SIGTERM
[Sat Apr 28 00:32:02 2007] [warn] child process 31832 still did not exit, sending a SIGTERM
[Sat Apr 28 00:32:02 2007] [warn] child process 31833 still did not exit, sending a SIGTERM
[Sat Apr 28 00:32:02 2007] [warn] child process 31836 still did not exit, sending a SIGTERM
[Sat Apr 28 00:32:02 2007] [warn] child process 31837 still did not exit, sending a SIGTERM
[Sat Apr 28 00:32:02 2007] [warn] child process 31838 still did not exit, sending a SIGTERM
[Sat Apr 28 00:32:02 2007] [warn] child process 31840 still did not exit, sending a SIGTERM
[Sat Apr 28 00:32:02 2007] [warn] child process 31841 still did not exit, sending a SIGTERM
[Sat Apr 28 00:32:44 2007] [crit] (48)Address already in use: make_sock: could not bind to port 443

What exactly is going on here? This has to be tally, and its been happening since we upgraded to the latest version of DA. Notice its 12:30am and thats when tally is running.
 
Last edited:
man, this is becoming very annoying. I dont know what the deal is but I cant keep doing this, everytime the server is half way busy and i try to restart apache i get
98)Address already in use: make_sock: could not bind to address 0.0.0.0:443
no listening sockets available, shutting down
Unable to open logs

Then it wont restart for like 10 minutes. When I do netstat it still shows things connected to port 80, sometimes I can go in and null route the ips and it will work. for some reason it is still holding on to the connection.
Ive tried every fix in here, stopping exim, restarting anything I can think of. Nothing works. restarting apache has became an ordeal now.
You says its not a directadmin issue, then what is it? I have apache 2 running on my other non-directadmin boxes with similar configurations just fine
 
felosi, it's exim issue, because it's taking apache's port (for some reason).
 
You must log in or register to reply here.
Back
Top