Bug #15230
closed
Unable to log into backend
Added by miikaawaadizi about 19 years ago.
Updated over 18 years ago.
Description
After installing from scratch, get this message trying to connect to the backend:
Fatal error: session_start(): Failed to initialize storage module: user (path: /tmp) in /usr/local/apache/typo3_src-3.8.1/typo3/index.php on line 240
All tables seem to be up from database.sql and populated.
Tried reinstalling from scratch, manually importing database.sql, compare (which always seems to find errors between that it just installed and what it wants to install). no matter how I try feeding it in, it doesn't work.
(side note: t3lib/stddb/tables.sql still has DEFAULT '0' in auto-increment entries, which borks in MySQL 4.1.11?)
FreeBSD
MySQL 4.1.11
Apache 1.*
(issue imported from #M1913)
it's not the permissions, they're fine, and everything was working fine with 3.8.0 on the same server.
Found it, it's the way Typo3 is calling the session handler
I found the hint when I did a search for "Failed to initialize storage module: user " in google, and eventually came across this page: http://bugs.php.net/bug.php?id=32330. At the bottom is a note:
Manually adding ini_set('session.save_handler', 'files') to the top of
PHP files, solves the problem.
So I added
ini_set('session.save_handler', 'files');
to the top of typo3conf/localconf.php, on the assumption that every part of Typo3 will include localconf.php, and everything appears to be working now. presumably this quick fix should go somewhere else than where I put it.
So it looks like the problem is something to do with the way sessions are being handled, the link I got this fix from explains a little more.
Hi,
in misc/phpcheck it is listed that the session.save_handler has to be set to "files". You can try to change this setting in your htaccess as well - however I see no point in including this in the core as it is normally not needed at all.
Greets, Sebastian
I had it set up correctly in both php.ini and in .htaccess, and it still wouldn't work. According to the bug report on the link I found, as well as similar ones, it still will happen even with the ini values set correctly in any combination of php.ini or .htaccess, requiring it to be specifically added to the script(s) themselves.
I can only assume that it's only happening on certain configurations, but the configuration I'm running seems to require the ini_set explicitly contained within the script, and given the number of similar bugs in other PHP apps I found googling that error message it's not just me has the particular configuration that ends up with this problem in session-using code.
This is a problem with PHP's handling of session_destroy() itself, and has ended up with a bug entry in PHP that's still open from march. If the workaround can be handled so simply it seems that it should be something added to core. Even if not added to core, I think this is worth at least a mention in the FAQ/HOWTO section as a fix for anyone who ends up with the same error.
Hi,
what do you think - which would be the most appropriate place to document this?
Greets, Sebastian
a good question, I liked the way you phrased it :)
Probably leave this bug open for consideration, note it on the FAQ/HOWTO with a link to the PHP bug entry? If there was a way to track how many people actually encounter the problem (if any!), it'd give the core team a better idea if this is something worth adding by default.
I'll add it to FAQ/HOWTO, but I'd appreciate it if someone can confirm first that putting the ini_set in localconf.php is the best place for it, or whether there's a better location. I put it there because it's the only file I know for sure is guaranteed to be included in every page, but that doesn't mean there's not a better place :) I'm also not sure how install tool (or anything else that writes to localconf.php) would behave with that entry present.
~miika
Hi miika,
adding it to localconf is perfectly fine, you just should watch out that it is placed before the install tool token.
Greets, Sebastian
Hi,
as described before, this is no TYPO3 issue. Closing the bug.
Greets, Sebastian
Also available in: Atom
PDF