Apache times out, can't restart, forced to reboot VPS

19 posts / 0 new
Last post
#1 Wed, 09/29/2010 - 01:28
SoftDux

Apache times out, can't restart, forced to reboot VPS

Apache crashes about every 2 weeks on one of my Virtualmin Virtual machines, and then I'm forced to reboot for it to work again.

When I login to VirtualMin, I can see Apache & BIND has stopped, and when I click on the start icon, I get this:

Failed to start service : Starting httpd: [Wed Sep 29 08:11:25 2010] [warn] NameVirtualHost 96.31.66.191:80 has no VirtualHosts (98)Address already in use: make_sock: could not bind to address [::]:80 (98)Address already in use: make_sock: could not bind to address 0.0.0.0:80 no listening sockets available, shutting down Unable to open logs [FAILED]

But there's nothing happening on port 80 when I connect to it. even when I stop / start / restart it from the commandline via SSH I get the same error.

Does anyone know what causes this, and how I can fix it?

Wed, 09/29/2010 - 08:19
andreychek

I'm not sure why it happens... though if it does happen again, you may want to try manually killing any Apache processes that are running. Even if it's not working correctly, if it's holding port 80 open, that may prevent the init script from working.

Whenever Apache crashes, do you see any errors in your Apache error log in /var/log?

-Eric

Wed, 09/29/2010 - 08:19
andreychek

I'm not sure why it happens... though if it does happen again, you may want to try manually killing any Apache processes that are running. Even if it's not working correctly, if it's holding port 80 open, that may prevent the init script from working.

Whenever Apache crashes, do you see any errors in your Apache error log in /var/log?

-Eric

Thu, 09/30/2010 - 03:30
SoftDux

well, that's the thing. Apache isn't (wasn't) running so I couldn't kill it. I already tried it. I already rebooted the VPS, just before I posted this topic, so I'll have to wait until it happens again before I can do any further digging into the problem.

Thu, 09/30/2010 - 09:31
andreychek

Hrm, if it happens again, is there any chance you could run "ps auxw", and attach the resulting output do this request?

Also, if there are any errors that show up in your Apache error log in /var/log, that'd be helpful too.

Thanks!

-Eric

Thu, 09/30/2010 - 11:11
SoftDux

Thanx Eric,

I'll check next time it happens again and report back here.

Fri, 10/22/2010 - 14:59
SoftDux

Ok, I just got this again and due to angry clients steaming down my neck I just killed it without checking what's running.

root@airgunsports:[~]$ ps ax | grep http
6707 ?        R    337:06 /usr/sbin/httpd
root@airgunsports:[~]$ /etc/init.d/
root@airgunsports:[~]$ /etc/init.d/httpd restart
Stopping httpd:                                            [FAILED]
Starting httpd: [Mon Oct 04 15:26:44 2010] [warn] NameVirtualHost 96.31.66.191:8                                                         0 has no VirtualHosts
(98)Address already in use: make_sock: could not bind to address [::]:80
(98)Address already in use: make_sock: could not bind to address 0.0.0.0:80
no listening sockets available, shutting down
Unable to open logs
                                                           [FAILED]
root@airgunsports:[~]$ killall -9 httpd
root@airgunsports:[~]$ /etc/init.d/httpd restart
Stopping httpd:                                            [FAILED]
Starting httpd: [Mon Oct 04 15:27:47 2010] [warn] NameVirtualHost 96.31.66.191:80 has no VirtualHosts
                                                           [  OK  ]

So the restart doesn't work, but the killall does.

root@airgunsports:[~]$ tail -n 100 /var/log/httpd/error_log
[Sun Oct 03 04:02:03 2010] [notice] Digest: generating secret for digest authentication ...
[Sun Oct 03 04:02:03 2010] [notice] Digest: done
[Sun Oct 03 04:02:03 2010] [notice] mod_python: Creating 4 session mutexes based on 256 max processes and 0 max threads.
[Sun Oct 03 04:02:03 2010] [notice] Apache/2.2.3 (CentOS) configured -- resuming normal operations
[Mon Oct 04 15:27:47 2010] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)
[Mon Oct 04 15:27:48 2010] [notice] Digest: generating secret for digest authentication ...
[Mon Oct 04 15:27:48 2010] [notice] Digest: done
[Mon Oct 04 15:27:48 2010] [notice] mod_python: Creating 4 session mutexes based on 256 max processes and 0 max threads.
[Mon Oct 04 15:27:48 2010] [notice] Apache/2.2.3 (CentOS) configured -- resuming normal operations

This is probably not worth much. Is there any other log that I can check, in another folder?

Mon, 10/04/2010 - 08:38
SoftDux

Ok, I just got this again and due to angry clients steaming down my neck I just killed it without checking what's running.

root@airgunsports:[~]$ ps ax | grep http 6707 ? R 337:06 /usr/sbin/httpd root@airgunsports:[~]$ /etc/init.d/ root@airgunsports:[~]$ /etc/init.d/httpd restart Stopping httpd: [FAILED] Starting httpd: [Mon Oct 04 15:26:44 2010] [warn] NameVirtualHost 96.31.66.191:8 0 has no VirtualHosts (98)Address already in use: make_sock: could not bind to address [::]:80 (98)Address already in use: make_sock: could not bind to address 0.0.0.0:80 no listening sockets available, shutting down Unable to open logs [FAILED] root@airgunsports:[~]$ killall -9 httpd root@airgunsports:[~]$ /etc/init.d/httpd restart Stopping httpd: [FAILED] Starting httpd: [Mon Oct 04 15:27:47 2010] [warn] NameVirtualHost 96.31.66.191:80 has no VirtualHosts [ OK ]

So the restart doesn't work, but the killall does.

root@airgunsports:[~]$ tail -n 100 /var/log/httpd/error_log [Sun Oct 03 04:02:03 2010] [notice] Digest: generating secret for digest authentication ... [Sun Oct 03 04:02:03 2010] [notice] Digest: done [Sun Oct 03 04:02:03 2010] [notice] mod_python: Creating 4 session mutexes based on 256 max processes and 0 max threads. [Sun Oct 03 04:02:03 2010] [notice] Apache/2.2.3 (CentOS) configured -- resuming normal operations [Mon Oct 04 15:27:47 2010] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec) [Mon Oct 04 15:27:48 2010] [notice] Digest: generating secret for digest authentication ... [Mon Oct 04 15:27:48 2010] [notice] Digest: done [Mon Oct 04 15:27:48 2010] [notice] mod_python: Creating 4 session mutexes based on 256 max processes and 0 max threads. [Mon Oct 04 15:27:48 2010] [notice] Apache/2.2.3 (CentOS) configured -- resuming normal operations

This is probably not worth much. Is there any other log that I can check, in another folder?

Wed, 10/13/2010 - 02:10
SoftDux

Eric, Can you please help with this? My client is really getting pissed off now and he's going to move somewhere else I suggested Virtualmin to him, but it seems VirtualMin doesn't deliver as well as other control panels.

Here's the output of ps auxw:

root@airgunsports:[~]$ ps auxw
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  0.0  0.0  10348   664 ?        Ss   Oct02   0:00 init [3]
root         2  0.0  0.0      0     0 ?        S<   Oct02   0:00 [migration/0]
root         3  0.0  0.0      0     0 ?        SN   Oct02   0:00 [ksoftirqd/0]
root         4  0.0  0.0      0     0 ?        S<   Oct02   0:00 [watchdog/0]
root         5  0.0  0.0      0     0 ?        S<   Oct02   0:00 [events/0]
root         6  0.0  0.0      0     0 ?        S<   Oct02   0:00 [khelper]
root         7  0.0  0.0      0     0 ?        S<   Oct02   0:00 [kthread]
root         9  0.0  0.0      0     0 ?        S<   Oct02   0:00 [xenwatch]
root        10  0.0  0.0      0     0 ?        S<   Oct02   0:00 [xenbus]
root        18  0.0  0.0      0     0 ?        S<   Oct02   0:00 [kblockd/0]
root        19  0.0  0.0      0     0 ?        S<   Oct02   0:00 [cqueue/0]
root        23  0.0  0.0      0     0 ?        S<   Oct02   0:00 [khubd]
root        25  0.0  0.0      0     0 ?        S<   Oct02   0:00 [kseriod]
root        84  0.0  0.0      0     0 ?        S    Oct02   0:00 [pdflush]
root        85  0.0  0.0      0     0 ?        S    Oct02   0:00 [pdflush]
root        86  0.0  0.0      0     0 ?        S<   Oct02   0:03 [kswapd0]
root        87  0.0  0.0      0     0 ?        S<   Oct02   0:00 [aio/0]
root       210  0.0  0.0      0     0 ?        S<   Oct02   0:00 [xenfb thread]
root       223  0.0  0.0      0     0 ?        S<   Oct02   0:00 [kpsmoused]
root       242  0.0  0.0      0     0 ?        S<   Oct02   0:00 [kstriped]
root       251  0.0  0.0      0     0 ?        S<   Oct02   0:08 [kjournald]
root       272  0.0  0.0      0     0 ?        S<   Oct02   0:00 [kauditd]
root       300  0.0  0.0  12652   828 ?        S<s  Oct02   0:00 /sbin/udevd -d
root       631  0.0  0.0      0     0 ?        S<   Oct02   0:00 [kmpathd/0]
root       632  0.0  0.0      0     0 ?        S<   Oct02   0:00 [kmpath_handlerd]
root       878  0.0  0.0   5908   572 ?        Ss   Oct02   0:01 syslogd -m 0
root       881  0.0  0.0   3804   320 ?        Ss   Oct02   0:00 klogd -x
dbus       917  0.0  0.0  21256   376 ?        Ss   Oct02   0:00 dbus-daemon --system
root       948  0.0  0.0  62624   684 ?        Ss   Oct02   0:00 /usr/sbin/sshd
root      1003  0.0  0.0  10764  1012 ?        S    Oct02   0:00 /bin/sh /usr/bin/mysqld_safe --datadir=/var/lib/mysql --socket=/var/lib/mysql/mysql.sock --log-error=/var/log/m
mysql     1051  0.1  1.4 267244 15068 ?        Sl   Oct02  27:08 /usr/libexec/mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --pid-file=/var/run/mysqld/mysqld.pid
root      1131  0.0  0.0   6052   564 ?        Ss   Oct02   0:00 /usr/sbin/dovecot
root      1134  0.0  0.1  62492  2096 ?        S    Oct02   0:00 dovecot-auth
dovecot   1160  0.0  0.1  34624  1612 ?        S    Oct02   0:00 pop3-login
dovecot   1162  0.0  0.1  34628  1544 ?        S    Oct02   0:00 imap-login
dovecot   1163  0.0  0.1  34628  1544 ?        S    Oct02   0:00 imap-login
dovecot   1164  0.0  0.1  34628  1540 ?        S    Oct02   0:00 imap-login
root      1190  0.0  0.1  54148  1768 ?        Ss   Oct02   0:00 /usr/libexec/postfix/master
postfix   1197  0.0  0.1  55164  1944 ?        S    Oct02   0:00 qmgr -l -t fifo -u
nobody    1200  0.0  0.1  49312  1336 ?        Ss   Oct02   0:00 proftpd: (accepting connections)
root      1216  0.0  0.0   6456   392 ?        Ss   Oct02   0:00 gpm -m /dev/input/mice -t exps2
root      1250  0.0  0.0  19704   648 ?        Ss   Oct02   0:01 crond
root      1258  0.0  0.0  46736   388 ?        Ss   Oct02   0:00 /usr/sbin/saslauthd -m /var/run/saslauthd -a pam
root      1261  0.0  0.0  48828   728 ?        S    Oct02   0:00 /usr/sbin/saslauthd -m /var/run/saslauthd -a pam
root      1262  0.0  0.0  48828   728 ?        S    Oct02   0:00 /usr/sbin/saslauthd -m /var/run/saslauthd -a pam
root      1263  0.0  0.0  46736   140 ?        S    Oct02   0:00 /usr/sbin/saslauthd -m /var/run/saslauthd -a pam
root      1264  0.0  0.0  46736   128 ?        S    Oct02   0:00 /usr/sbin/saslauthd -m /var/run/saslauthd -a pam
mailman   1278  0.0  0.1  96468  1580 ?        Ss   Oct02   0:00 /usr/bin/python /usr/lib/mailman/bin/mailmanctl -s -q start
mailman   1289  0.0  0.3  98536  3372 ?        S    Oct02   0:01 /usr/bin/python /usr/lib/mailman/bin/qrunner --runner=ArchRunner:0:1 -s
mailman   1290  0.0  0.3  98616  3412 ?        S    Oct02   0:02 /usr/bin/python /usr/lib/mailman/bin/qrunner --runner=BounceRunner:0:1 -s
mailman   1291  0.0  0.3  98656  3388 ?        S    Oct02   0:01 /usr/bin/python /usr/lib/mailman/bin/qrunner --runner=CommandRunner:0:1 -s
mailman   1292  0.0  0.3  98564  3384 ?        S    Oct02   0:01 /usr/bin/python /usr/lib/mailman/bin/qrunner --runner=IncomingRunner:0:1 -s
mailman   1293  0.0  0.3  98668  3408 ?        S    Oct02   0:01 /usr/bin/python /usr/lib/mailman/bin/qrunner --runner=NewsRunner:0:1 -s
mailman   1294  0.0  0.3  98608  3424 ?        S    Oct02   0:01 /usr/bin/python /usr/lib/mailman/bin/qrunner --runner=OutgoingRunner:0:1 -s
mailman   1295  0.0  0.3  98664  3372 ?        S    Oct02   0:01 /usr/bin/python /usr/lib/mailman/bin/qrunner --runner=VirginRunner:0:1 -s
mailman   1296  0.0  0.3  98660  3380 ?        S    Oct02   0:00 /usr/bin/python /usr/lib/mailman/bin/qrunner --runner=RetryRunner:0:1 -s
root      1300  0.0  0.0  70744  1008 ?        Ss   Oct02   0:00 /usr/libexec/webmin/virtual-server/lookup-domain-daemon.pl
root      1305  0.0  0.1  69340  2036 ?        Ss   Oct02   0:00 /usr/bin/perl /usr/libexec/usermin/miniserv.pl /etc/usermin/miniserv.conf
root      1310  0.0  0.2  72056  2816 ?        Ss   Oct02   0:11 /usr/bin/perl /usr/libexec/webmin/miniserv.pl /etc/webmin/miniserv.conf
root      1313  0.0  0.0   3788   428 tty1     Ss+  Oct02   0:00 /sbin/mingetty tty1
root      1314  0.0  0.0   3788   428 tty2     Ss+  Oct02   0:00 /sbin/mingetty tty2
root      1315  0.0  0.0   3788   428 tty3     Ss+  Oct02   0:00 /sbin/mingetty tty3
root      1316  0.0  0.0   3788   428 tty4     Ss+  Oct02   0:00 /sbin/mingetty tty4
root      1317  0.0  0.0   3788   428 tty5     Ss+  Oct02   0:00 /sbin/mingetty tty5
root      1318  0.0  0.0   3788   428 tty6     Ss+  Oct02   0:00 /sbin/mingetty tty6
root      1319  0.0  0.0   3788   428 ?        Ss+  Oct02   0:00 /sbin/mingetty console
dovecot   3167  0.0  0.2  33884  2212 ?        S    Oct09   0:00 pop3-login
apache    3919 24.8  0.5 253264  5796 ?        R    Oct10 1147:02 /usr/sbin/httpd
root      7632  0.0  1.3  79044 13980 ?        S    Oct11   0:00 /usr/libexec/webmin/rpc.cgi
root     12045  0.0  0.1  46880  1096 ?        S    09:00   0:00 crond
root     12050  0.0  0.1   8668  1140 ?        Ss   09:00   0:00 /bin/bash /usr/share/clamav/freshclam-sleep
root     12054  0.0  0.0   3788   468 ?        S    09:00   0:00 sleep 9714
root     12187  0.0  0.3  90240  3548 ?        Ss   09:04   0:00 sshd: root@pts/0
postfix  12189  0.0  0.2  54212  2236 ?        S    09:04   0:00 pickup -l -t fifo -u
root     12267  0.0  0.1  10896  1464 pts/0    Ss   09:05   0:00 -bash
root     12291  0.0  0.0  10460   892 pts/0    R+   09:06   0:00 ps auxw
postgres 26031  0.0  0.3  65512  4080 ?        S    Oct12   0:00 /usr/bin/postmaster -p 5432 -D /var/lib/pgsql/data
postgres 26044  0.0  0.0  54692  1040 ?        S    Oct12   0:00 postgres: logger process
postgres 26046  0.0  0.1  65512  1248 ?        S    Oct12   0:00 postgres: writer process
postgres 26047  0.0  0.0  55692  1004 ?        S    Oct12   0:00 postgres: stats buffer process
postgres 26048  0.0  0.1  54876  1184 ?        S    Oct12   0:00 postgres: stats collector process
dovecot  26815  0.0  0.2  34624  2212 ?        S    Oct11   0:00 pop3-login
root@airgunsports:[~]$

The logs doesn't contain anything useful:

root@airgunsports:[~]$ tail -n100 /var/log/httpd/error_log
[Sun Oct 10 04:02:06 2010] [notice] Digest: generating secret for digest authentication ...
[Sun Oct 10 04:02:06 2010] [notice] Digest: done
[Sun Oct 10 04:02:06 2010] [notice] mod_python: Creating 4 session mutexes based on 256 max processes and 0 max threads.
[Sun Oct 10 04:02:06 2010] [notice] Apache/2.2.3 (CentOS) configured -- resuming normal operations
root@airgunsports:[~]$ tail -n500 /var/log/httpd/error_log
[Sun Oct 10 04:02:06 2010] [notice] Digest: generating secret for digest authentication ...
[Sun Oct 10 04:02:06 2010] [notice] Digest: done
[Sun Oct 10 04:02:06 2010] [notice] mod_python: Creating 4 session mutexes based on 256 max processes and 0 max threads.
[Sun Oct 10 04:02:06 2010] [notice] Apache/2.2.3 (CentOS) configured -- resuming normal operations

root@airgunsports:[~]$ tail -n500 /var/log/httpd/access_log
root@airgunsports:[~]$
Wed, 10/13/2010 - 09:59
andreychek

I suggested Virtualmin to him, but it seems VirtualMin doesn't deliver as well as other control panels.

I'm sorry that your frustrated, but blaming Virtualmin for Apache dieing every few weeks isn't going to help get this fixed.

We try hard to answer/resolve the issues that arise here in the forums, whether they're from GPL or Pro users, but sometimes the issues in question require a deeper look that can't really be helped by a third party like us.

We'll help you keep Virtualmin running, and we also help answer all sorts of other questions that may arise as a result of running a Linux server... but ultimately, you still have to sysadmin your box, we can't do that for you :-)

And the problem with being a sysadmin is that sometimes the issues that arise are hard to resolve :-)

In your case, there just aren't any errors to suggest what the issue is. I've thrown out some ideas, but I'm just really not sure what would cause the problem you're seeing with Apache. I'm also not aware of anyone else seeing that issue.

There's a handful of users who've had problems during the logrotate at 4am on Sundays, but those are always accompanied by a disk full error. It's also always at 4am on Sundays that the problem occurs.

One thing you might consider doing as a bandaid would be to edit /etc/init.d/apache2, and in the "stop" and "restart" sections, you may want to add a "killall" line in there to get Apache stopping and restarting more cleanly, since it seems like an Apache process is getting stuck.

There's only two other thoughts I have --

  1. Could you be running out of RAM? If your VPS ran low on RAM, the Linux kernel has to start killing off processes to prevent the box from completely falling over. Take a peek at "free -m", and see how much free RAM you have available. Also make sure that you have plenty of swap.

  2. As a shot in the dark, are you using FCGID for any of your sites? If so, what if you switch them over to CGI? FCGID should work just fine, but if you're somehow running into an FCGID bug, moving over to CGI may resolve that.

If those don't help, you really may need to consider hiring sometime to come take a look. They may be able to setup some monitoring and traces in Apache, and dig down to what's the root cause of this issue.

Let us know how that goes!

-Eric

Fri, 10/22/2010 - 10:11 (Reply to #10)
SoftDux

Hi Eric,

I don't think RAM & disk space is an issue here:

root@airgunsports:[~]$ free -m total used free shared buffers cached Mem: 1024 815 208 0 33 336 -/+ buffers/cache: 445 578 Swap: 1023 0 1023 root@airgunsports:[~]$ df -h Filesystem Size Used Avail Use% Mounted on /dev/sda1 20G 3.0G 16G 16% / none 512M 0 512M 0% /dev/shm root@airgunsports:[~]$

As matter of interest though, I have this problem on random days, so it has no relationship with the "Sunday log rotate" issue you're refering to.

root@airgunsports:[~]$ last -10 root pts/0 vc-41-29-165-99. Fri Oct 22 16:55 still logged in reboot system boot 2.6.18-164.2.1.e Fri Oct 22 09:49 (07:08) root pts/0 196-215-111-223. Fri Oct 22 09:42 - down (00:06) root pts/0 196-210-237-79.d Wed Oct 13 09:05 - 10:37 (01:32) root pts/0 196-210-169-192. Mon Oct 4 15:26 - 20:17 (04:50) reboot system boot 2.6.18-164.2.1.e Sat Oct 2 05:11 (20+04:37) reboot system boot 2.6.18-164.2.1.e Wed Sep 29 08:14 (2+20:56) root pts/0 196-210-169-192. Wed Sep 22 03:04 - 08:16 (05:12) reboot system boot 2.6.18-164.2.1.e Mon Sep 13 16:38 (15+15:35) root pts/1 196-215-47-159.d Mon Sep 13 16:32 - down (00:04)

But at the same time I notice that the problem is 9 days apart. The time I ever need to login to this machine via SSH is to fix the issue, or reboot the VPS if I can't fix the issue. I don't know what significance this has though?

At the same time I don't see anyhing in crontab which runs on 9 days schedules, or even 8 day schedules:

0,5,10,15,20,25,30,35,40,45,50,55 * * * * /etc/webmin/virtual-server/collectinfo.pl 0,5,10,15,20,25,30,35,40,45,50,55 * * * * /etc/webmin/status/monitor.pl 7 * * * * /etc/webmin/virtual-server/spamconfig.pl 0 * * * * /etc/webmin/virtual-server/bw.pl 52 3 * * * /etc/webmin/webalizer/webalizer.pl /home/airgunsports.co.za/logs/access_log 27 5 * * * /etc/webmin/virtualmin-awstats/awstats.pl airgunsports.co.za @daily /etc/webmin/virtual-server/backup.pl --id 126958914128585 @daily /root/fixapache

This morning when it crashed again I had to reboot since the normall "killall -9 httpd && /etc/init.d/apache restart" didn't fix the problem.

I'm using the default VirtualMin config, so I doubt if it's running FCGID, I didn't change any settings, nor could I even find where to change to FCGID just now.

Wed, 10/13/2010 - 10:59
ronald
ronald's picture

Actually I have this exact problem on two of my VPS's.
It started after an Apache update from CentOS.

First after 1 week Virtualmin shows at the information page that Apache is down, but it isn't.
Then the second week Apache stops working, I have to killall and start Apache again.
No errors in the logs what so ever.
My workaround is to kill apache every 10 days and start it again.

When Apache is doing a graceful restart after a sysrotate or logrotate on Fridays, 1 process hangs and Apache cant start up again. So far I can see. I have to kill that process and all is fine again.

The difference is the 2 VPS's are running Virtualmin GPL version and are build from a different image as the other VPS's which have no issues at all.
1 is running Virtualmin Pro version and the other is only running webmin GPL, both without issues.

Without issues is build from CentOS 5.4 64-bit Xen instance with base OS
With issues is build from CentOS 5.4 64-bit Xen instance with Virtualmin GPL

All machines are running Linux 2.6.18-164.11.1.el5xen on x86_64 and all are set up the same (fcgid)
I want all my machines running the exact same thing. Ram is no issue, neither is drive space.

Fri, 10/22/2010 - 10:18
andreychek

Well, FCGID is the default :-)

To change FCGID to CGI, you can go into Server Configuration -> Website Options, and set "PHP script execution mode" to "CGI". But you'd need to do that for each Virtual Server.

Also, Joe will be rolling out a new version of FCGID soon. If there's a bug in the FCGID module, it's possible that will correct the issue as well.

-Eric

Fri, 10/22/2010 - 15:01 (Reply to #13)
SoftDux

aah ok, not at all where I expected it to be.

I see it's set to:

Apache mod_php (run as Apache's user)

... which is neither of the 2 options mentioned. Should I change it?

Fri, 10/22/2010 - 11:21
Locutus

I don't know if this might help here, but when I had issues with a memory leak with Apache, PHP and the MySQL module under Windows, I applied a workaround in form of setting MaxRequestsPerChild to a reasonable value, causing Apache to regularly spawn new child processes (under Windows: threads) every so many requests. Might avoid running into lockup situations for some process here.

Also, @Softdux, a hint: You should put command output in   tags, thus having them formatted in a way that is much better readable.

Fri, 10/22/2010 - 15:02 (Reply to #15)
SoftDux

Thanx, I'll change it to the < code > option instead :)

Fri, 10/22/2010 - 11:19
Locutus

Sorry... Double-post. Clicked twice or something. :)

Wed, 11/03/2010 - 03:08
SoftDux

this is really getting annoying and just to stop from loosing this client I'm forced to move him to a cPanel server.

Wed, 11/03/2010 - 04:39
Locutus

Well, did you try the MaxRequestsPerChild option I suggested? Also, if you experience such regular trouble, it might be an idea to fully auto-restart Apache every week or so.

I don't think that it's VMin's fault if some application crashes randomly. If there is a severe configuration problem with Apache or PHP, they wouldn't even start but rather log errors. If there is some "unfortunate" configuration that causes slow but steadily building trouble, regular restarts can help.

But first, you need to narrow down the cause for the problems. Check logfiles, change PHP execution mode to mod_php, monitor CPU and memory load, up/downgrade package versions if trouble started after an update (the Apache/PHP coders are merely humans too and make mistakes) etc.

One more hint: When VMin considers Apache not running although the process is still there, that is usually due to missing PID file (in /var/run). Otherwise, to give more help on this, we'd need to get a detailed update on what exactly the current problem is and what steps you've done so far.