ID: 32330 Comment by: labsy at seznam dot org Reported By: [EMAIL PROTECTED] Status: Assigned Bug Type: Session related Operating System: * PHP Version: 4CVS, 5CVS (2005-03-17) Assigned To: sniper New Comment:
I was experiencing this problem one year ago, but now it reoccured. I run PHP 5.0.2 on Win 2000/IIS I act as WebHosting provider, host about 170 domains. Now, one thing that attracted my attention was, that one of my users installed osCommerce portal few days ago. Since osCommerce handles sessions its own way, it seems to corrupt session handling function in PHP all over my server. Any file which has session_start() at the beginning, needs to be loaded twice, first attempt to load page produces the mentioned error, but after reload session initializes normally. I have session.save_handler = files session.save_path = "C:\PHP\sessiondata" ;this dir is world writeable All my PHP files only use session_start() and $_SESSION[] variable cals, no other session functions are used. It worked fine, until one of my users installed osCommerce portal. Previous Comments: ------------------------------------------------------------------------ [2005-03-31 16:37:51] evenh+phpbug at pvv dot ntnu dot no I experienced this one too, but only when using tavi.sourceforge.net. This intrigued me, and I've developed a little script to give information related to this issue. The script at http://tavi.sourceforge.net/bug32330.php shows a counter which jumps around at it own free will, seemingly. This due to the changing host underneath, see changing $_SERVER['SERV_ADDR']. The script always uses /tmp, and it's always writeable, but it's not on the same computer! This could be fixed by using a common path, as is done in http://tavi.sourceforge.net/bug32330fix.php . And now the counter works, and I don't get the "Failed to initialize..."-message either. The reason for not getting the message, I've experienced, could be related to accidentially calling session_start() twice... Either in the same script, or script running in concurrent time space. Or maybe the lack of session_write_close()? Note that both the supplied script would include phpinfo() if adding "?a" (or anything at all) after the script name. The scripts will be available for some weeks. Feel free to copy them if needed... ;-) But the messages seems to have gone away, so I'm happy. For now. Regards, Even Holen ------------------------------------------------------------------------ [2005-03-31 06:33:58] [EMAIL PROTECTED] I don't see how this relates to my problem besides the error message. I ask you guys kindly to open a new report about your specific problem. Your problem has no relation to session handler loosing when calling session_destroy. ------------------------------------------------------------------------ [2005-03-30 17:42:49] todd dot trann at palidar dot com RedHat 9 PHP 4.3.9 from RPM (php-4.3.9-11.rh90.art) Zend Engine 1.3.0, Optimizer 2.5.5 I am experiencing the same problem: the error indicates storage module "user", yet php.ini has it set to "files", and nowhere in my code do I change it to "user". The problem comes and goes as the page is reloaded. A PHP page with no session code does not exhibit the problem. Todd ------------------------------------------------------------------------ [2005-03-24 22:27:36] scliburn at trtinfo dot com mfischer, I'm positive about the session.save_handler and the session_module_name not being set anywhere. I'm emailing direct my link to my php info page. no sessions nothing on the page expect for phpinfo(); the save_handler is set to files. No joke. another test i've done was to have a copy of a website running on 2 servers (same code, same db) Server 1: Redhat php 4.3.9 Zend engine 1.3.0 - no problems Server 2: php 4.3.10 Zend Zend engine 1.3.0 Optimizer 2+ - problems ------------------------------------------------------------------------ [2005-03-24 21:43:44] [EMAIL PROTECTED] Do you use session_destroy in your code? Are you sure you aren't calling session_module_name somewhere? Does a clean page, with no session_start but only phpinfo in it, also tell you that the session module in use is 'user' rather then files? ------------------------------------------------------------------------ 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/32330 -- Edit this bug report at http://bugs.php.net/?id=32330&edit=1
