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

SoftDux · September 29, 2010, 6:28am

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?

Eric · September 29, 2010, 1:19pm

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

Eric · September 29, 2010, 1:19pm

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

SoftDux · September 30, 2010, 8:30am

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.

Eric · September 30, 2010, 2:31pm

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

SoftDux · September 30, 2010, 4:11pm

Thanx Eric,

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

SoftDux · October 4, 2010, 1:38pm

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?

SoftDux · October 13, 2010, 7:10am

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 root         1  0.0  0.0  10348   664 ? root         2  0.0  0.0      0     0 ? root         3  0.0  0.0      0     0 ? root         4  0.0  0.0      0     0 ? root         5  0.0  0.0      0     0 ? root         6  0.0  0.0      0     0 ? root         7  0.0  0.0      0     0 ? root         9  0.0  0.0      0     0 ? root        10  0.0  0.0      0     0 ? root        18  0.0  0.0      0     0 ? root        19  0.0  0.0      0     0 ? root        23  0.0  0.0      0     0 ? root        25  0.0  0.0      0     0 ? root        84  0.0  0.0      0     0 ? root        85  0.0  0.0      0     0 ? root        86  0.0  0.0      0     0 ? root        87  0.0  0.0      0     0 ? root       210  0.0  0.0      0     0 ? root       223  0.0  0.0      0     0 ? root       242  0.0  0.0      0     0 ? root       251  0.0  0.0      0     0 ? root       272  0.0  0.0      0     0 ? root       300  0.0  0.0  12652   828 ? root       631  0.0  0.0      0     0 ? root       632  0.0  0.0      0     0 ? root       878  0.0  0.0   5908   572 ? root       881  0.0  0.0   3804   320 ? dbus       917  0.0  0.0  21256   376 ? root       948  0.0  0.0  62624   684 ? root      1003  0.0  0.0  10764  1012 ? mysql     1051  0.1  1.4 267244 15068 ? root      1131  0.0  0.0   6052   564 ? root      1134  0.0  0.1  62492  2096 ? dovecot   1160  0.0  0.1  34624  1612 ? dovecot   1162  0.0  0.1  34628  1544 ? dovecot   1163  0.0  0.1  34628  1544 ? dovecot   1164  0.0  0.1  34628  1540 ? root      1190  0.0  0.1  54148  1768 ? postfix   1197  0.0  0.1  55164  1944 ? nobody    1200  0.0  0.1  49312  1336 ? root      1216  0.0  0.0   6456   392 ? root      1250  0.0  0.0  19704   648 ? root      1258  0.0  0.0  46736   388 ? root      1261  0.0  0.0  48828   728 ? root      1262  0.0  0.0  48828   728 ? root      1263  0.0  0.0  46736   140 ? root      1264  0.0  0.0  46736   128 ? mailman   1278  0.0  0.1  96468  1580 ? mailman   1289  0.0  0.3  98536  3372 ? mailman   1290  0.0  0.3  98616  3412 ? mailman   1291  0.0  0.3  98656  3388 ? mailman   1292  0.0  0.3  98564  3384 ? mailman   1293  0.0  0.3  98668  3408 ? mailman   1294  0.0  0.3  98608  3424 ? mailman   1295  0.0  0.3  98664  3372 ? mailman   1296  0.0  0.3  98660  3380 ? root      1300  0.0  0.0  70744  1008 ? root      1305  0.0  0.1  69340  2036 ? root      1310  0.0  0.2  72056  2816 ? root      1313  0.0  0.0   3788   428 tty1 root      1314  0.0  0.0   3788   428 tty2 root      1315  0.0  0.0   3788   428 tty3 root      1316  0.0  0.0   3788   428 tty4 root      1317  0.0  0.0   3788   428 tty5 root      1318  0.0  0.0   3788   428 tty6 root      1319  0.0  0.0   3788   428 ? dovecot   3167  0.0  0.2  33884  2212 ? apache    3919 24.8  0.5 253264  5796 ? root      7632  0.0  1.3  79044 13980 ? root     12045  0.0  0.1  46880  1096 ? root     12050  0.0  0.1   8668  1140 ? root     12054  0.0  0.0   3788   468 ? root     12187  0.0  0.3  90240  3548 ? postfix  12189  0.0  0.2  54212  2236 ? root     12267  0.0  0.1  10896  1464 pts/0 root     12291  0.0  0.0  10460   892 pts/0 postgres 26031  0.0  0.3  65512  4080 ? postgres 26044  0.0  0.0  54692  1040 ? postgres 26046  0.0  0.1  65512  1248 ? postgres 26047  0.0  0.0  55692  1004 ? postgres 26048  0.0  0.1  54876  1184 ? dovecot  26815  0.0  0.2  34624  2212 ? root@airgunsports:[~]$


STAT START   TIME COMMAND
 Ss   Oct02   0:00 init [3]
 S<   Oct02   0:00 [migration/0]
 SN   Oct02   0:00 [ksoftirqd/0]
 S<   Oct02   0:00 [watchdog/0]
 S<   Oct02   0:00 [events/0]
 S<   Oct02   0:00 [khelper]
 S<   Oct02   0:00 [kthread]
 S<   Oct02   0:00 [xenwatch]
 S<   Oct02   0:00 [xenbus]
 S<   Oct02   0:00 [kblockd/0]
 S<   Oct02   0:00 [cqueue/0]
 S<   Oct02   0:00 [khubd]
 S<   Oct02   0:00 [kseriod]
 S    Oct02   0:00 [pdflush]
 S    Oct02   0:00 [pdflush]
 S<   Oct02   0:03 [kswapd0]
 S<   Oct02   0:00 [aio/0]
 S<   Oct02   0:00 [xenfb thread]
 S<   Oct02   0:00 [kpsmoused]
 S<   Oct02   0:00 [kstriped]
 S<   Oct02   0:08 [kjournald]
 S<   Oct02   0:00 [kauditd]
 S<s  Oct02   0:00 /sbin/udevd -d
 S<   Oct02   0:00 [kmpathd/0]
 S<   Oct02   0:00 [kmpath_handlerd]
 Ss   Oct02   0:01 syslogd -m 0
 Ss   Oct02   0:00 klogd -x
 Ss   Oct02   0:00 dbus-daemon --system
 Ss   Oct02   0:00 /usr/sbin/sshd
 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
 Sl   Oct02  27:08 /usr/libexec/mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --pid-file=/var/run/mysqld/mysqld.pid
 Ss   Oct02   0:00 /usr/sbin/dovecot
 S    Oct02   0:00 dovecot-auth
 S    Oct02   0:00 pop3-login
 S    Oct02   0:00 imap-login
 S    Oct02   0:00 imap-login
 S    Oct02   0:00 imap-login
 Ss   Oct02   0:00 /usr/libexec/postfix/master
 S    Oct02   0:00 qmgr -l -t fifo -u
 Ss   Oct02   0:00 proftpd: (accepting connections)
 Ss   Oct02   0:00 gpm -m /dev/input/mice -t exps2
 Ss   Oct02   0:01 crond
 Ss   Oct02   0:00 /usr/sbin/saslauthd -m /var/run/saslauthd -a pam
 S    Oct02   0:00 /usr/sbin/saslauthd -m /var/run/saslauthd -a pam
 S    Oct02   0:00 /usr/sbin/saslauthd -m /var/run/saslauthd -a pam
 S    Oct02   0:00 /usr/sbin/saslauthd -m /var/run/saslauthd -a pam
 S    Oct02   0:00 /usr/sbin/saslauthd -m /var/run/saslauthd -a pam
 Ss   Oct02   0:00 /usr/bin/python /usr/lib/mailman/bin/mailmanctl -s -q start
 S    Oct02   0:01 /usr/bin/python /usr/lib/mailman/bin/qrunner --runner=ArchRunner:0:1 -s
 S    Oct02   0:02 /usr/bin/python /usr/lib/mailman/bin/qrunner --runner=BounceRunner:0:1 -s
 S    Oct02   0:01 /usr/bin/python /usr/lib/mailman/bin/qrunner --runner=CommandRunner:0:1 -s
 S    Oct02   0:01 /usr/bin/python /usr/lib/mailman/bin/qrunner --runner=IncomingRunner:0:1 -s
 S    Oct02   0:01 /usr/bin/python /usr/lib/mailman/bin/qrunner --runner=NewsRunner:0:1 -s
 S    Oct02   0:01 /usr/bin/python /usr/lib/mailman/bin/qrunner --runner=OutgoingRunner:0:1 -s
 S    Oct02   0:01 /usr/bin/python /usr/lib/mailman/bin/qrunner --runner=VirginRunner:0:1 -s
 S    Oct02   0:00 /usr/bin/python /usr/lib/mailman/bin/qrunner --runner=RetryRunner:0:1 -s
 Ss   Oct02   0:00 /usr/libexec/webmin/virtual-server/lookup-domain-daemon.pl
 Ss   Oct02   0:00 /usr/bin/perl /usr/libexec/usermin/miniserv.pl /etc/usermin/miniserv.conf
 Ss   Oct02   0:11 /usr/bin/perl /usr/libexec/webmin/miniserv.pl /etc/webmin/miniserv.conf
 Ss+  Oct02   0:00 /sbin/mingetty tty1
 Ss+  Oct02   0:00 /sbin/mingetty tty2
 Ss+  Oct02   0:00 /sbin/mingetty tty3
 Ss+  Oct02   0:00 /sbin/mingetty tty4
 Ss+  Oct02   0:00 /sbin/mingetty tty5
 Ss+  Oct02   0:00 /sbin/mingetty tty6
 Ss+  Oct02   0:00 /sbin/mingetty console
 S    Oct09   0:00 pop3-login
 R    Oct10 1147:02 /usr/sbin/httpd
 S    Oct11   0:00 /usr/libexec/webmin/rpc.cgi
 S    09:00   0:00 crond
 Ss   09:00   0:00 /bin/bash /usr/share/clamav/freshclam-sleep
 S    09:00   0:00 sleep 9714
 Ss   09:04   0:00 sshd: root@pts/0
 S    09:04   0:00 pickup -l -t fifo -u
 Ss   09:05   0:00 -bash
 R+   09:06   0:00 ps auxw
 S    Oct12   0:00 /usr/bin/postmaster -p 5432 -D /var/lib/pgsql/data
 S    Oct12   0:00 postgres: logger process
 S    Oct12   0:00 postgres: writer process
 S    Oct12   0:00 postgres: stats buffer process
 S    Oct12   0:00 postgres: stats collector process
 S    Oct11   0:00 pop3-login

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:[~]$

Eric · October 13, 2010, 2:59pm

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 –

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.
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

ronald · October 13, 2010, 3:59pm

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.

SoftDux · October 22, 2010, 3:11pm

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.

Eric · October 22, 2010, 3:18pm

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

Locutus · October 22, 2010, 4:19pm

Sorry… Double-post. Clicked twice or something.

Locutus · October 22, 2010, 4:21pm

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.

SoftDux · October 22, 2010, 7:59pm

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?

SoftDux · October 22, 2010, 8:01pm

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?

SoftDux · October 22, 2010, 8:02pm

Thanx, I’ll change it to the < code > option instead

SoftDux · November 3, 2010, 8:08am

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

Locutus · November 3, 2010, 9:39am

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.