Forum Moderators: coopster
Worse, there's not much I can do about it. Apparently someone at the hosting service spent the afternoon tinkering with the server / php settings. Not sure. All I get is "we are aware of the problem and we are working on it now".
Great! So all my ad campaigns are paused. No one can view my site. And I keep deleting the core dumps because apparently they accumulate towards my disk usage!
So, shall we speculate what was changed on the server to cause the problem?
If you're using IE, go to TOOLS then INTERNET OPTIONS and hit the ADVANCED tab. Scroll down until you find "Show Friendly HTTP Error Messages" and UNCHECK this box - then revisit the page you're having a problem with to see the real error.
[Mon Jun 20 21:57:00 2005] [error] [client xx.xx.#*$!.xx] Premature end of script headers: /home/domain/public_html/index.php
[Mon Jun 20 21:56:41 2005] [error] [client xx.xx.#*$!.xx] Premature end of script headers: /home/domain/public_html/index.php
I think about all I can do is whine and wait.
All the PHP code started with:
<?
PHP CODE HERE
?>
I changed all my PHP code to read:
<?php
PHP CODE HERE
?>
and the problem went away. Could it be the same thing happening to you here? I've also seen text saved in Windows/DOS format do that and running them through a "Save as Unix" text format type procedure will fix it immediately.
Burner
Burner
<?php
<speculation>
Here's what happened. The sys admin jumped on a plane to New Orleans this afternoon, and his idiot helper screwed the pooch. You folks call the office when you get settled in. I'm told 'tomorrow' before service is restored. How long does it take to reboot a server?
</speculation>
Since the server is still serving html just fine, I altered my index.html page with a custom message and then pointed the 500 error to the index.
ErrorDocument 500 http://www.domain.com/index.html
:~/ Burner
BTW... Enjoy your vacation!
I'm also curious as to what happened. A good guess is that someone was tinkering with Apache and not PHP, and didn't quite get it right. I learned a while back that's its useless to yell at the poor sap who has to answer the phones. I was able to determine that it's gone at least to level 2. Maybe the other sites on the server aren't reporting problems. But here's the real truth. I will never be told what caused the problem.
foreach ($detarr as $value) {
...
$vwrf = wordwrap($value, 30, "\n", 1);
...
}
and its returning this error
Warning: wordwrap() expects parameter 1 to be string, array given in /home/blah/blah.php on line 298.
Interesting... what would cause that? Something in php.ini? Version is 4.3.11
The rest of the site has stopped returning a 500 error and now simply displays a blank page. <sigh>
In testing, a very simple 'hello world' script executes properly.
I don't know what version the upgrade was for, but I'm guessing it was V5.
Apparently, for the moment, the sys admin is stumped. Can anyone shed some light (perhaps with more information?)
To hasten this along, I've commented a line in one include and now my scripts run. There are a few problems associated with not having some of the info I was using, that blows!
Looking very closely at this what I've seen is that arrays are not being handled properly. See msg 11, and then this is what I've had to disable in an include that utilizes the class. I don't believe the problem is with the class, its looks like its with certain internal array processes.
function in_array_multi($needle, $haystack)
{
if(!is_array($haystack)) return $needle == $haystack;
foreach($haystack as $value) if(in_array_multi($needle, $value)) return true;
return false;
}
//$my_return = in_array_multi($my_test, $alluas);
The boolean value of $my_return is the show stopper. (I believed I described it as an array return earlier.) By changing a single line in my script the return is handled properly.
the code
include ("checkbot.inc"); // returns $my_return as bool
if (!$my_return) {
include ("sessreg.inc");
}
modified code
include ("checkbot.inc");
if ($my_return == 'false') {
include ("sessreg.inc");
}
Of course, this still poses a big problem since those particualr lines reside in every script, and not an include. So for now all I can do is prevent the return value of checkbot from being set. More and more this looks like a php.ini setting. But, is it also something I should have prevented? .. looks that way ..
FWIW, to recap, this line of code did not cause the original 500 error condition. Some changes on the server by my host has caused this problem. Apparently they have now restored the system, but is looks like settings have been changed.
what OS on the server itself? (I read the whole thread but didn't spend a ton of time so if you mentioned it, sorry)
do they maintain the seperate versions one cgi and one apache module or some other?
I am guessing wildly that a lib had to be upgraded and now they have nuked the old version because some shared/core lib is out of sync
The only version I have any info on tells me the Server API is Apache. I haven't waded thru all of the configure commands that were used, and they are a bit harder to define than the core directive settings.
I have lost the ability to use phpMyAdmin, which I assume is controlled by the other installation of PHP. Here's an example of the errors:
Warning: Illegal offset type in /home/vdeck/public_html/phpMyAdmin/libraries/grab_globals.lib.php on line 74
The scripts do not have a problem reading from the db.
The one thing that might give me a clue is back in msg 14. When I uncomment the line for $my_return everything stops. The script simply will not run past that point, and there are no errors.
.. just royally screwed up the install
hehe, he just knows ;)
Last night the level 2 tech, who is suspect is really the systems operator, tried to assure me that PHP has been restored. However, the build date/time do not jive with that story. There was actually a minor version upgrade, and that happened following the initial problems. The level 2 support fellow suggested that PHP may have been installed as CGI and not as Apache. Not sure how that might affect things, but I'd guess it subtly affects how things work. As an aside, we lost our power last night as I was on the phone with the tech, and it was just restored in the last hour. So not only was my web site not working right, I couldn't do anything to try to fix the problems. So I lit a candle and waited.
I have one script that still refuses to work. Oddly, it is the only script I have placed in my cgi-bin folder. Anyway, it's been moved and works again.
digitalv. I appreciate your comments regarding IE. I did give it a try, but the pages wouldn't even load and error messages were non-existent (friendly or otherwise).
coopster and jatar_k, I passed along the suggestion that the build was possibly corrupted. But what system admin is going to listen to his customers?
This experience is just the sort of thing that concerned me when I first started PHP. Not so much the initial problems, that sort of thing is going to happen. More of a concern is that the operating parameters of PHP may get changed and scripts stop working. The boss was definitely giving me the evil eye, but he also understands that our site would have far fewer capabilities without PHP.
And, when I get back it looks like I'll have to rebuild by wiki forum, it's still completely hosed. All I can do for now is password protect the directory to keep people out. What a way to run a forum!
that would make a big difference and could be the whole issue in a nutshell
