php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #17614 After a few hours, PHP scripts are returned as-is and not run
Submitted: 2002-06-05 14:06 UTC Modified: 2002-09-11 11:15 UTC
Votes:1
Avg. Score:5.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:0 (0.0%)
Same OS:1 (100.0%)
From: bmerry at cs dot uct dot ac dot za Assigned:
Status: No Feedback Package: Scripting Engine problem
PHP Version: 4.2.1 OS: Debian/unstable
Private report: No CVE-ID: None
View Developer Edit
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: bmerry at cs dot uct dot ac dot za
New email:
PHP Version: OS:

 

 [2002-06-05 14:06 UTC] bmerry at cs dot uct dot ac dot za 
First some more details:
- PHP from Debian package php4_2:4.2.1-3.
- Apache-ssl from Debian package apache-ssl_1.3.24.3+1.48-2
- Linux 2.4.18

The website is running a "main" site, a number of virtual hosts with PHP disabled (engine off) and a virtual host in which UserDir's are enabled. UserDir scripts are put into safe mode via a <Directory /home/*/public_html> block.

After running the server for a few hours, the main site still works fine but all user scripts are returned to the client verbatim e.g. I have a script that just contains
<?php
phpinfo();
?>
and when I 'view source' in the browser that is exactly what I see.

When I SIGHUP apache, all is well again for an hour or so and then it stops working again. Looking in the apache logs I don't see any indication of the problem. I can't even tell if this is an Apache problem (not passing the script to the PHP module or a PHP problem) - if you have any test I can do for this let me know.

I haven't attached any server info since it is rather large. You can see the output of phpinfo() at http://www.smuts.uct.ac.za/phpinfo.php. The test script above is at http://users.smuts.uct.ac.za/~bmerry/test.php. It will either give you the output of phpinfo() or the script verbatim. If you want other info (such as the Apache config) let me know.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2002-06-05 14:15 UTC] sniper@php.net 
Instead of 'SIGHUP', why aren't you doing a full stop and start of Apache?? There is some problem with DSOs and SIGHUP
(which I can't now remember what it was).

apachectl stop
apachectl start

those only should be used when dealing with DSOs.

--Jani
 [2002-06-06 05:06 UTC] bmerry at cs dot uct dot ac dot za 
Thanks, I wasn't aware of the SIGHUP problem (and apparently neither are the Debian guys). Unfortunately stopping and starting the server again didn't work either - it worked for about 15 minutes.

Worse, it seems as though after it stops working it will occasionally work again: I set up a cron job to request the page every 5 minutes and at some odd times it would suddenly work. It also worked for a while after logrotate SIGHUP'ed apache.

There is also a vhost on that server that has as its DocumentRoot /home/bob/public_html, and the PHP scripts for that site seem to break as well i.e. it seems to be related to the <Directory> block rather than the vhost itself. I'm going to try shuffling some directives around e.g. moving the safe_mode from that <Directory> block into the vhost block and will let you know.
 [2002-06-06 10:56 UTC] bmerry at cs dot uct dot ac dot za 
I've moved the php config stuff out of the <Directory> block and into the VirtualHost block, and now it seems to be working perfectly. Would that make it an Apache problem?
 [2002-06-13 10:00 UTC] sniper@php.net 
It does sound like an Apache problem but I wouldn't bet any
money on that horse. :) You propably should submit a bug report about it to them too? (or search their database if someone else has had similar problem?) 

Just in case, try the latest CVS snapshot of PHP too:

http://snaps.php.net/php4-latest.tar.gz
 [2002-09-11 11:15 UTC] sniper@php.net 
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.
 [2002-10-31 00:53 UTC] mark at nospam dot gov 
I show the same problem under 4.2.3, under debian (using their "unstable" packages) and the same problem under slackware 8.0.0 running a hand rolled version, nothing fancy just curl and mcrypt, gd, however I've found that if the client hits Reload in their browser the script executes instead of sending the source as-is, and the problem is solved for a while. Both machines running 1.3.27/4.2.3
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Sun Dec 22 01:01:30 2024 UTC