ID: 25876 Comment by: peter at mapledesign dot co dot uk Reported By: golden at riscom dot com Status: Open Bug Type: Session related Operating System: freebsd 4.8 PHP Version: 4.3.3 New Comment:
I can confirm that this bug is still present on Apache 1.3.X with PHP 4.3.10. I am trying to set the session.save_handler back to files manually, but consider the need to do this (assuming it works) to be a bug - it should default back to this, not stick in a process with the previous status. I am encountering this problem now at two different hosting companies, and never had this problem before they upgraded to 4.3.10 Previous Comments: ------------------------------------------------------------------------ [2004-12-26 11:25:12] [EMAIL PROTECTED] Confirmed on SF.net 4.3.10 Linux Try several times until error. http://farplugins.sourceforge.net/test/php.php <? session_start(); echo $PHPSESSID; ?> http://farplugins.sourceforge.net/test/in.php <?php phpinfo(); ?> /home/groups/f/fa/farplugins/htdocs/test/.htaccess <IfModule mod_php4.c> php_value session.save_path "/home/groups/f/fa/farplugins/htdocs/test/tmp" </IfModule> ------------------------------------------------------------------------ [2004-09-28 23:12:14] coadmin at hostings dot pl We have the same problem. FreeBSD 4.10-STABLE, PHP 4.3.8, Apache 1.3.31 how to repeat: <? session_start(); echo $PHPSESSID; ?> then refresh the website a many times. you will receive an error: Fatal error: session_start(): Failed to initialize storage module: user (path: /tmp) in /home/xxx/public_html/index.php on line 2 the problem still exists also when using custom dir for saving session files. ------------------------------------------------------------------------ [2004-08-16 17:32:30] ron at dse dot nl Clearing the x-bit did not solve the problem. Probably this bug is not really related to the X-bit-hack but merely very similar in it's effects. The way to work around this bug is by avoiding php ini settings in all .htaccess files on your Apache server and instead put them in the application. For Drupal for instance, I moved these settings to conf.php by using ini_set() there. Squirrelmail even has a special config_local.php that you can use for this. More info on my particular setup: Apache 1.3.29 with o.a. mod_suexec and mod_rewrite PHP 4.3.8 (but same issue with 4.3.4) applications installed within same vhost Hope this will help developers find this annoying bug. ------------------------------------------------------------------------ [2004-08-08 20:48:47] ron at dse dot nl Spent over a day troubleshooting as well. I think the real problem is described here: http://bugs.php.net/bug.php?id=25753 Although the suggested bug fix over there seems to have been incorporated in up to version 4.3.8, the behaviour still exists. The bug is easily triggered by running Squirrelmail and Drupal off the same Apache server as in my case. Drupal sets the session.save_handler to 'user' by a directive in the .htaccess file that comes with the installation. If, by accident, the next request by the same Apache child process is for a squirrelmail user, then the squirrelmail session_start() fails with 'Failed to initialize storage module'. This happens because the session.save_handler is still set to user instead of file, it is not reset to the master value for the child process. It is a matter of random luck which child process will serve the squirrelmail request so that explains the intermittent occurance. As mentioned by rasmus this "only happens on text/html files with the executable bit set". Clearing the bit for all of the squirrelmail PHP files seems to be useful a workaround. Just perform a find . -name '*.php' -type f -exec chmod -x {} ';' in your squirrelmail (or other PHP application) directory and restart your Apache server (for some reason this was necessary). ------------------------------------------------------------------------ [2004-05-05 07:27:32] tkaeser at gmx dot net Hi, had the same error, added the following line before starting the session: ini_set('session.save_handler', 'files'); this fixed it in my case... I don't have any idea why this works, got it from http://lists.mushaake.org/pipermail/php/Week-of-Mon-20031117/004091.html ------------------------------------------------------------------------ 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/25876 -- Edit this bug report at http://bugs.php.net/?id=25876&edit=1
