ID: 23580 Comment by: php at techmeridian dot com Reported By: maximiliano dot marques at bol dot com dot br Status: Feedback Bug Type: Apache related Operating System: Conectiva Linux 8 Kernel 2.4.19 PHP Version: 4.3.2 New Comment:
Yes I have just tried the latest snap from snaps.php.net and this problem still exists! Previous Comments: ------------------------------------------------------------------------ [2003-08-15 08:33:28] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip And adjust the version accordingly if problem persists. ------------------------------------------------------------------------ [2003-08-07 01:38:57] ns at canada dot com Looks like the caching isn't happening quite like I thought it was. Running this script a couple of times in the same httpd process: <?php print "getmypid() = " . getmypid() . " "; print "ini_get(include_path) = " . ini_get("include_path") . "<br />\n"; print "Setting include_path...<br />\n"; ini_set("include_path", "/home/users/noam/ web"); print "getmypid() = " . getmypid() . " "; print "ini_get(include_path) = " . ini_get("include_path") . "<br />\n"; ?> shows that the include_path is always as configured in php.ini at the beginning of the script. (i.e. the ini_set doesn't persist.) Using Apache 2.0.47. ------------------------------------------------------------------------ [2003-08-07 01:13:14] ns at canada dot com We've been having this problem as well. In support of the caching hypothesis, here's some info I've collected. This is PHP 4.3.2; phpinfo() is available at http://nbtsc.org/~noam/info.php The include_path for our server is set in php.ini to ".:/usr/share/pear". phpinfo() verifies this as the master setting. Output from 'ps xaf' showing the httpd processes: 30908 ? SN 0:02 httpd 30930 ? SN 0:00 \_ httpd 30932 ? SN 0:00 | \_ httpd 30936 ? SN 1:52 | \_ httpd 30962 ? SN 2:00 | \_ httpd ... (30963 through 30985) 30986 ? SN 0:01 | \_ httpd 19881 ? SN 0:00 \_ httpd 19882 ? SN 0:00 | \_ httpd 19884 ? SN 1:41 | \_ httpd ... (19885 through 19908) 19909 ? SN 0:01 | \_ httpd 11727 ? SN 0:00 \_ httpd 11728 ? SN 0:00 \_ httpd 11730 ? SN 0:15 \_ httpd ... (11731 through 11754) 11755 ? SN 0:00 \_ httpd I then ran 'w3m -dump' in a loop, loading this simple php script 100 times: <?php print "getmypid() = " . getmypid() . " "; print "ini_get(include_path) = " . ini_get("include_path") . "<br />\n"; ?> I find the output rather interesting. All the requests served by PIDs in the 30xxx range (one branch of the httpd process tree) are have consistently incorrect include_path="tes/info.nbtsc.org/photos/" (which is a fragment of the path '/home/sites/info.nbtsc.org/photos'). All the requests served by PIDs in the 19xxx range have consistently correct include_path=".:/usr/share/pear". The requests served by PIDs in the 11xxx range have varying include_paths; sometimes, when the same process served a second request, it had a different include path from the first time. The include_paths from the 11xxx range are either ".:/usr/share/pear", "2.php", or (in hexadecimal) 0x58 0xCC 0x20 0x20. What I haven't been able to figure out is where these include_paths are coming from. I will see what more I can track down, and zeev, I can check with the main server administrator to see about getting you temporary access. What level of access would you need? Noam ------------------------------------------------------------------------ [2003-07-23 10:33:02] [EMAIL PROTECTED] I'm trying to reproduce this, but so far without any success. I tried to stress-test PHP with multiple vhosts and see if there are any 'leaks' of include_paths - but after hundreds of thousands of requests, there were none. I'm very interested in what you say about the single-process mode. Basically, what you describe is *not* the behavior PHP is supposed to display. The include_path settings should go back to its original setting at the end of each request. This is also the behavior that I'm seeing in my setup. How did you determine that the include_path setting remains 'cached'? If that is really the case, then it would greatly help if you could provide me with temporary access to your server, so I can debug this. If it's not the case, then it appears we're back in square one... ------------------------------------------------------------------------ [2003-07-16 07:42:21] katana at katana-inc dot com We have experienced the same problem here since a few month. I was told that it was gonna be fixed in 4.3.2 but it looks like it's still here (we were warned by a disk full error because of the error logged filled with failed includes from an auto_prepend file that belongs to another vhost). We can't upgrade to a snapshot since it is a production server. We are running Gentoo but the same was happening with RedHat 8, running apache 1.3.27. The only fix was to change MaxRequestPerChild to 1... ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/23580 -- Edit this bug report at http://bugs.php.net/?id=23580&edit=1
