|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
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
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 Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
Block user comment
Status: Assign to:
Bug Type:
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
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 The test script above is at 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.


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2002-06-05 14:15 UTC]
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.


 [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]
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:
 [2002-09-11 11:15 UTC]
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-2017 The PHP Group
All rights reserved.
Last updated: Sun Nov 19 01:31:42 2017 UTC