Project

General

Profile

Actions

Bug #15230

closed

Unable to log into backend

Added by miikaawaadizi about 19 years ago. Updated over 18 years ago.

Status:
Closed
Priority:
Should have
Category:
Install Tool
Target version:
-
Start date:
2005-11-22
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
3.8.1
PHP Version:
4
Tags:
Complexity:
Is Regression:
Sprint Focus:

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)

Actions #1

Updated by Christian Trabold about 19 years ago

Seems that your tmp/-Folder is not writable for the webserver or not present in the file system.

Please have a look at the Install lists found here:

http://lists.netfielders.de/cgi-bin/mailman/listinfo/

eg.

http://lists.netfielders.de/cgi-bin/mailman/listinfo/typo3-install

Actions #2

Updated by miikaawaadizi about 19 years ago

it's not the permissions, they're fine, and everything was working fine with 3.8.0 on the same server.

Actions #3

Updated by miikaawaadizi about 19 years ago

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.

Actions #4

Updated by Sebastian Kurfuerst almost 19 years ago

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

Actions #5

Updated by miikaawaadizi almost 19 years ago

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.

Actions #6

Updated by Sebastian Kurfuerst almost 19 years ago

Hi,
what do you think - which would be the most appropriate place to document this?
Greets, Sebastian

Actions #7

Updated by miikaawaadizi almost 19 years ago

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

Actions #8

Updated by Sebastian Kurfuerst almost 19 years ago

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

Actions #9

Updated by Sebastian Kurfuerst almost 19 years ago

Hi,
as described before, this is no TYPO3 issue. Closing the bug.
Greets, Sebastian

Actions

Also available in: Atom PDF