Session error on NEW install of Classic 3.1.2

Omeka Classic Installing and Upgrading
1

We’re having problems with moving Classic to a new server. To keep it simple, I’ve attempted a new install (classic 3.1.2) to test with (still get same error). I’ve searched the forum here, and none of the previous issues seem to apply here. Looking for help! More details:

OS: RHEL 9.3 with all prereq libraries
PHP: 8.1.27 - installed as PHP-FPM

Checked the following (found from searches):

  • verified Omeka 3.1.2 is compatible with PHP 8.1
  • verified httpd and php-fpm user is apache, and can write to /var/lib/php/session/
  • verified session support is enabled, session.auto_start is off, save_handler is set to files, and save_path is set to /var/lib/php/session
  • new install, but cleared caches. also tested in Mozilla and Edge (started with Chrome)
  • we don’t run other Zend apps, but I know other websites on server are using Wordpress, and that seems to be using session dir just fine (writeable).
  • or are sessions now in the database only, e.g. omeka_sessions? (which looks very weird for a new install - 209804 records???) if that’s the case, the rest of the DB is there, so the installer worked and one would expect the sessions db to work?
  • uncommenting application/config/config.ini’s session.saveHandler = “” results in a session file in /var/lib/php/session/ … but the same error.
  • gc_probability is 1

Error log:

2024-04-15T14:23:18-07:00 ERR (3): Zend_Session_Exception: The session has already been started.  The session id must be set first. in /app/www/WEBSITE/html/collections/application/libraries/Zend/
Session.php:681
Stack trace:
#0 /app/www/WEBSITE/html/collections/application/libraries/Zend/Session.php(440): Zend_Session::setId()
#1 /app/www/WEBSITE/html/collections/application/libraries/Zend/Session/Namespace.php(143): Zend_Session::start()
#2 /app/www/WEBSITE/html/collections/application/libraries/Omeka/Controller/Plugin/Admin.php(64): Zend_Session_Namespace->__construct()
#3 /app/www/WEBSITE/html/collections/application/libraries/Zend/Controller/Plugin/Broker.php(309): Omeka_Controller_Plugin_Admin->preDispatch()
#4 /app/www/WEBSITE/html/collections/application/libraries/Zend/Controller/Front.php(941): Zend_Controller_Plugin_Broker->preDispatch()
#5 /app/www/WEBSITE/html/collections/application/libraries/Zend/Application/Bootstrap/Bootstrap.php(106): Zend_Controller_Front->dispatch()
#6 /app/www/WEBSITE/html/collections/application/libraries/Zend/Application.php(384): Zend_Application_Bootstrap_Bootstrap->run()
#7 /app/www/WEBSITE/html/collections/application/libraries/Omeka/Application.php(73): Zend_Application->run()
#8 /app/www/WEBSITE/html/collections/admin/index.php(28): Omeka_Application->run()
#9 {main}

Not sure what else to try or look at…

[edited to remove personal info]

2

Sessions are by default stored in the database in Omeka, and yes it’s the omeka_sessions table. Setting saveHandler manually lets you set anything you want, or go back to file-based sessions.

If you have a bunch of records in your sessions table, you might be looking at the table from the site you’re trying to move and not the “fresh” one? The sessions table is blank on a new install. You can truncate the sessions table if you’d like, it will just essentially log everyone out (at least, once the site is working).

This isn’t necessarily related to the session storage though. You get this message when the session’s already started when the code runs that tries to configure the session. If you have any other messages in our error log on in the PHP logs they might shine a light on the situation.

The actual error here happens when we try to start up our session and the constant SID is already defined. Normally that’s defined by the PHP session system when it starts, but maybe you have some situation where it’s already set for some reason? You could try checking for that constant with some simple echo/var_dump/die type debugging code somewhere like the start of index.php or bootstrap.php.

3

Thank you for the response.

I will try a couple things tomorrow including a fresh install just to be sure. Pretty sure I double checked that the db was blank (it’s a different server than the new or old server) before install.

Unfortunately there are absolutely no other messages in the web server error log (or omeka’s) other than what I gave.

I’ll try adding some debugging code as you suggest. I’m not a PHP expert, but I assume I can attempt to work backwards on the stack trace and see - or where you suggest. Will report back!

4

Ok, did a fresh install, wiped db. Verified session table was clean after install (so that must have been us).

  1. did install form to create db, but did NOT go to admin page yet
  2. verified session table was empty
  3. went to admin page and got error. saw a new entry in session table (so that’s getting created there). It also matches the one found in $_COOKIE[‘0bb086da72f4ea516ce56a34c309835a’]
  4. made the following code changes:

admin/index.php (line 16, after include bootstrap):

defined('SID') && print "1 SID is '" . SID . "'.";

admin/index.php (end of file, after init->run()):

defined('SID') && print "9 SID is '" . SID . "'.";

application/libraries/Zend/Session.php, line 681 (where exception message is):

defined('SID') && print "5 SID is '" . SID . "'.";
echo "SID is '" . SID . "' test is '" . self::$_unitTestEnabled . "'.";

The resultant output (cleaned up, not including aforementioned stack trace) is:


5 SID is ''.
SID is '' test is ''.
9 SID is ''.

So, that implies SID is not set after bootstrap (test 1), but is after test 5 (and obviously test 9). But it’s set to ‘’ (empty), which I believe means the session was set [correctly] with a cookie.

After a lot of playing around, I’ve found the following solved my session issue:

  • changing session.sid_bits_per_character=6 to session.sid_bits_per_character=5

I am assuming this is either a compatibility issue or a bug, but I can certainly live with changing that value for this server or website.

After changing that, and restarting browser/clearing cache, we now get the login page. I’m handing this back to the webmaster to move forward on, but hopefully that’s the only bugaboo!

5

Hmm, that’s useful information. I’ll check around to see if I can confirm an issue with higher sid_bits_per_character. I can’t immediately come up with a reason why it would matter, though.

6

My understanding of that is that it’s “bitness” - meaning more bits, meaning more character possibilities. Or to the point, I believe the session id can include characters like a dash, and some others.

https://www.php.net/manual/en/session.configuration.php#ini.session.sid-bits-per-character

My absolute guess might be Omeka or Zend (and is this Zend 1.12, I believe?) might not like the special characters and normalizes to “” because of that? Esp when putting it into a database?

Of course, the old server has session entries of things like:

-1839+or+1=2
+|+/bin/cat+/etc/passwd+|+
;window.top._arachni_js_namespace_taint_tracer.log_execution_flow_sink()

…etc… so maybe there’s not strict checking… :slight_smile:

Thanks for walking through this with me!