Forum Moderators: phranque
Lately the server where I am hosted (not a commercial server, I am hosted by an aquaintance) has been locking up from time to time. The problem seems to be that php and/or mysql gets overloaded, in the end crashing the webserver.
So far, my host or I have not been able to get anywhere near to determining a cause. I have been able to identify some of what happens through the error_log, however. It seems as if one thing that occurs is that includes from the CMS I use (ExpressionEngine) start failing, though it seems possible that this happens because PHP has already been overloaded. But this is an example of what I get in the error_log:
[client 163.**.69.12] PHP Warning: main(http://DOMAIN/Digest/): failed to open stream: HTTP request failed! l\xdc\xf8\xbf@\xb8$ in /PATH/Westeros03.html on line 1
[client 163.**.69.12] PHP Warning: main(): Failed opening 'http://DOMAIN/Digest/' for inclusion (include_path='.:/usr/share/pear') in /PATH/Westeros03.html on line 1
Any thoughts on the cause? Or is there anything my host or I can do to get more information logged?
[edited by: jdMorgan at 9:37 pm (utc) on Nov. 3, 2006]
[edit reason] Obscured IP Address (privacy) [/edit]
Check all of these first. It is definitely a problem with your include, though.
Good luck!
The problem seems to be that php and/or mysql gets overloaded, in the end crashing the webserver.
If your host cannot figure this out then you might consider a new host. I would think they might want to resolve this as opposed to having the entire server down for any reason.
Unfortunatly, switching hosts isn't an option, as I am hosted for free by an acquaintance and the site would be far too expensive to host elsewhere. So, I am trying to help my host out with the troubleshooting. I had hoped that maybe the error_log would have some clues for someone who knows what to look for.
... in the end crashing the webserver.
What do you mean exactly ... the apache's httpd process dies and gets restarted -- or -- the entire webserver box crashes and gets rebooted?
Perhaps what you see is not the reason of the crash but a side effect of another problem.
So you may want to look at the server's log as well (/var/log/messages) to check if the box may have had some flaky hardware problems at that time (disk I/O or whatever).
Kind regrds,
R.
No, the include is from the same server.
Sorry, I meant the included file. I seen the 'http://' on the front end of your include failure message and assumed the included file was on a different domain and/or server. Usually includes from the same box are not performed using a protocol wrapper but pulled using a local filename path.
Since ftp, telnet and other services continue to function, I am guessing that I mean that the httpd process crashes, not the whole server.
So you may want to look at the server's log as well (/var/log/messages) to check if the box may have had some flaky hardware problems at that time (disk I/O or whatever).
Ah, good suggestion. Will see if that can be looked at by my host. Thanks. :)
coopster,
Usually includes from the same box are not performed using a protocol wrapper but pulled using a local filename path.
True, but in this case using that include method is the only way since the pages being included are generated dynamically via a CMS. So they don't actually exist anywhere physically on the server.
Checking the logs is a good start, no doubt. You may also want to look at the Apache version, PHP version and any possible conflicts. There may also be a bug report for your same configuration, updating to the latest CVS might be in order.
Hopefully your logs point you in the right direction first though.
And what's with the squirrely characters? " l\xdc\xf8\xbf@\xb8$"
Looks suspicious.
"It works most of the time" doesn't necessarily mean it has anything to do with server load. It could just indicate a seldom-used execution path.
My guess is some stray, non-printable characters in a not-often-used instance of the URL, along with code that doesn't anticipate failure of the HTTP request, perhaps then looping for infinate retries.
Look in your Apache error log to see why the request to DOMAIN/Digest failed.
Are you talking about the error_log, or something different? Because that one doesn't give any more than what I posted (except I had to edit out the urls according to forum policy).
And what's with the squirrely characters? " l\xdc\xf8\xbf@\xb8$"
Yes, very odd. I have no idea where they come from, though. I get different ones for each error.
My guess is some stray, non-printable characters in a not-often-used instance of the URL, along with code that doesn't anticipate failure of the HTTP request, perhaps then looping for infinate retries.
No, the URLs definitely check out fine. The URL that caused the error I quoted, for example, is working fine just now.
Are you talking about the error_log, or something different?
Yes, I am referring to the error_log. I would also look at the access log. You are NOT looking for references to the original webpage made by the user, but references to the page requested in the embedded URL. (i.e. the request to your CMS.)
You should see either an error log entry, or a successful or unsuccessful reference in the access log. Actually, I think the access log may be more fruitful. I'll bet you see that the server returned a 404 not found error.
Don't assume that the URLs as printed are the URLs that are actually being requested. Some error-checking code seems to be complaining about some characters with high-bits on. It could be that the code that prints the URL filters the high-bits.
