PHP :: Bug #17614 :: After a few hours, PHP scripts are returned as-is and not run

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:

CVE-ID:

None

View Developer Edit

Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.

php.net Username: php.net Password:

Quick Fix:	(description)
	Block user comment
Status:		Assign to:
Package:
Bug Type:
Summary:
From:	bmerry at cs dot uct dot ac dot za
New email:
PHP Version:		OS:

New/Additional Comment:

[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.net \| support \| documentation \| report a bug \| advanced search \| search howto \| statistics \| random bug \| login
go to bug id or search bugs for


Copyright © 2001-2025 The PHP Group All rights reserved.	Last updated: Sun Mar 16 13:01:27 2025 UTC