Set up a clean Joomla installation (tested with Joomla 3.9.15).
Change database connection in configuration.php so that it fails.
Error telling "Database Connection failed"
Warning: session_start(): Failed to read session data: user (path: /var/lib/php/sessions) in /usr/share/nginx/www/pub/registrierung/libraries/joomla/session/handler/native.php on line 260
Error: Failed to start application: Failed to start the session
Current environment: Joomla 3.9.15, PHP 7.1.33
I'm pretty sure this situation occured with other versions, too.
JSessionHandlerNative->doSessionStart does
// Ok to try and start the session
if (!session_start())
{
throw new RuntimeException('Failed to start the session');
}
It seems the first database query will be done from within session handler.
When removing throw new RuntimeException('Failed to start the session');
, the database connection error will be shown, as it should. Instead, The class thinks the php session is misconfigurated and shows an error which is actually misleading.
Labels |
Added:
?
|
PHP doesn’t offer any mechanism to get an error for why a session didn’t start (there’s no
json_last_error()
for the session API). You might be able to add extra info if there’s a message inerror_get_last()
, but just flat out removing the Exception throwing from that part of the code is not a valid fix.(FWIW the message isn’t “entirely misleading”, in context the exception being thrown has a valid message, it just lacks any additional detail about the reason for the exception which is what causes the debugging headache)
My words were misleading. I did not mean to remove the exception, this would be bad indeed.
I see what's the difficulty. However, a failing session_start() is normally related to things like misconfigurations of PHP sessings, and as such this error message would lead to head scratching in some cases.
Wouldn't it make more sense to first establish a database connection (and error if it is misconfigurated) and then start the session?
Wouldn't it make more sense to first establish a database connection (and error if it is misconfigurated) and then start the session?
Not necessarily. This only applies if you're using the Joomla default configuration of using the database as a session store (which I wish would change but *shrug*
, the filesystem handler is plenty reliable as long as the host config is not FUBAR). And for the same reasons I moved the explicit $session->start()
call out of where the session was being created, we don't want an explicit $db->connect()
call to happen just because the database object is created. The API is well optimized in the aspect of either I/O operations or network connections for external connections (cache, database, and session) aren't performed until needed, it just ends up that because of order of operations and how PHP handles error stacking that the real error in this case (database connection issue) is getting absorbed and not reported up when the "can't start session" error is being shown. And like I said, error_get_last()
may help create a more useful error message here but that's probably still going to be iffy at best.
I see, then the code should stay as it is.
I suggest to extend the thrown error message text to something like:
Failed to start the session (Check PHP session path and database connection if sessions are managed in database.)
Status | New | ⇒ | Expected Behaviour |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2020-04-15 14:54:23 |
Closed_By | ⇒ | jwaisner |
Status | Expected Behaviour | ⇒ | Closed |
Closed_Date | 2020-04-15 14:54:23 | ⇒ | 2020-04-15 14:54:24 |
Closed_By | jwaisner | ⇒ | joomla-cms-bot |
Set to "closed" on behalf of @jwaisner by The JTracker Application at issues.joomla.org/joomla-cms/28109
Closing as expected behavior at this time.
PHP doesn’t offer any mechanism to get an error for why a session didn’t start (there’s no
json_last_error()
for the session API). You might be able to add extra info if there’s a message inerror_get_last()
, but just flat out removing the Exception throwing from that part of the code is not a valid fix.(FWIW the message isn’t “entirely misleading”, in context the exception being thrown has a valid message, it just lacks any additional detail about the reason for the exception which is what causes the debugging headache)