ID: 32330 Comment by: evenh+phpbug at pvv dot ntnu dot no 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 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 Previous Comments: ------------------------------------------------------------------------ [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? ------------------------------------------------------------------------ [2005-03-24 18:43:34] scott at trtinfo dot com scott => scliburn are one in the same :). We have not been using any custom session handlers. We have been utilizing the PHP built in session handlers. My session.save_handler all have been set to "files". I have noticed the error message still states: Fatal error: session_start(): Failed to initialize storage module: user (path: /tmp) Take notice to the module "user", however this is my php.ini (i've located and updated all instances of the php.ini); session.save_handler = files I was also unable to produce this error on another machine (win2003-webedition) which has thread saftey on. Not sure if that is helpful. This error has only produced itself after upgrading Zend 2+ on php 4.3.9, 4.3.10, & 5.03 (I cannot produce this error on 5.02 with Zend 2+) yet. I'm taking a wild non-technical quess in that the save_handler setting is obviously getting reset during a php request, but have no clue as to where. I know it's not the code calling to this. I wrote it. Zend? Heres another twist. I do have another site that is running osCommerce with custom session handlers and that site doesnot produce this error (once again, yet). odly enough ------------------------------------------------------------------------ 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
