Why do site visitors end up with two sessions after logging in?

Question

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.

Answer 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.