1

I have an up and running Drupal 6.30 (latest) site, but some users are having problems logging in. This is due to the user having two rows in the sessions table, one for uid 0 and one for their uid (this one appears after logging in). The session for uid 0 should be removed from the database after authentication, but it is not.

Question: How could a user end up with two sessions or why is the uid 0 not removed?

Steps to repeat and further background:

  1. Truncate sessions table
  2. Delete all cookies in browser
  3. Visit site homepage. This gets a new session for uid 0.
  4. Login Successful login is seen in the watchdog table. uid x appears in the session table. The uid 0 session is not deleted, but I think it should be.

I believe that this causes the browser to send both sessions and Drupal only expects one, so if the uid 0 session is seen by Drupal then the request is seen to be from an anonymous user.

The user is redirected back to the homepage and is presented the login form again and is not logged in. Ironically, the user's name appears in the footer of the homepage as a logged in user.

Additional info: I managed to get some debug info from a user. After logging in the browser also has two sessions. Both have the same SESSxxxxxx name but different values. So it seems the old session is not being destroyed properly.

Full disclosure: I've posted this question on the Drupal Community Forum but haven't had any response after 48h, I hope it's ok to cross post it here.

  • FYI It's just bug reports/feature requests that need to be handled on Drupal.org - support requests like this are perfectly on-topic here even if they've been posted on D.o – Clive Apr 3 '14 at 12:53
  • Policy is what @Clive said, but thank you for being polite none the less :) – Mołot Apr 3 '14 at 13:04
1

User always have one session at a time. Every time he logs in or out, new session is created.

Drupal 6 does not clean session table. I don't know if it is supposed to or not, but both my experience and simple Google search reveals it fails to do it.

So you have current session of an logged-in user, and outdated session data he left behind when he stopped to be anonymous.

If this really bothers you, consider moving sessions to APC or Memcached, it's much faster than database way, and unused data will be purged by the storage system even if Drupal will not trigger cleanup.

The user is redirected back to the homepage and is presented the login form again and is not logged in. Ironically, the user's name appears in the footer of the homepage as a logged in user.

This behaviour I experienced only once - when database was misconfigured, and it reported inserts to session table as successful, but next request failed to read freshly inserted data. Apparently it was database caching, but unable to fix it, we ended up with sessions in RAM, as noted above.

  • By experience session cleaning is inconsistent. Some uid 0 sessions will be immediately (not by cron) deleted, these users will be able to login. Other uid 0 sessions remain after the new session is created and this (as far as I can tell) prevents login. So yes it bothers me. – Craig Apr 3 '14 at 13:20
  • 1
    @Craig This isn't necessarily a Drupal issue: rymland.org/en/blogs/boaz/2_jan_09/… – Clive Apr 3 '14 at 13:26
  • @Clive Thanks for the link, it was useful. I think the steps listed in the question rule this out as a cause though. – Craig Apr 3 '14 at 13:44
  • @Craig I experienced a lot of weirdness with sessions in d6 (and two migrations between hosting companies did not help, really). Re-configuring sessions from ground up, and kicking them into memory, was what helped. But I admit I never got to understand why and how. Answer will be updated in few minutes, I have something to add. – Mołot Apr 3 '14 at 14:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.