#17614 [Fbk->NoF]: After a few hours, PHP scripts are returned as-is and not run

ID: 17614 Updated by: sniper@php.net Reported By: bmerry@cs.uct.ac.za -Status: Feedback +Status: No Feedback Bug Type: Scripting Engine problem Operating System: Debian/unstable PHP Version: 4.2.1 New Comment: 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. Previous Comments: ------------------------------------------------------------------------ [2002-06-13 10:00:25] 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-06-06 10:56:57] bmerry@cs.uct.ac.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-06 05:06:26] bmerry@cs.uct.ac.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-05 14:15:11] 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-05 14:06:16] bmerry@cs.uct.ac.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. ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/?id=17614&edit=1