Tag Archive for session

3,700,000 Session Records

Hey, Drupal fans! I would like to alert you to an issue that I encountered today. While doing some unrelated database work, I found that our sessions table had grown to over 3,700,000 records. While not posing any immediate danger to the website, this may have been slowing down backup and just isn’t tidy. Drupal relies on PHP garbage collection to cleanup session tables, but apparently this does not happen properly on Debian systems. Solutions include setting PHP defaults to encourage garbage collection and installing the Session Expire module. The problem is fixed in Drupal 7 through php.ini overrides.

I chose to install Session Expire on our Drupal 6 site, feeling that Drupal should clean up its own garbage. It also has the advantage of providing a choice between deleting anonymous sessions, authenticated user sessions, or both. The module is extremely simple and could be implemented on a Drupal 7 site if one would prefer to delete old sessions that way. The module took an hour to delete 3.7m records on a test copy of our site. You might prefer to just truncate the table instead, though this will log off people currently using the site.

Drupal 6.17 and session cookies

I have had no problems with Drupal core updates for years. I finally got burned when I installed Drupal 6.17. This update no longer removes “www.” from admin-set cookie domains, which was preventing admins from using different cookie domains for www.example.com and example.com websites. The change broke login for many of our users until I solved the problem.

How did this seemingly esoteric issue affect us? In addition to www.catlin.edu, we also run live development and test copies of our website, so that we may build new features and try changes without affecting users. Some time ago, we manually set $cookie_domain in settings.php so that sites could have separate cookies, allowing a developer to log into the different sites as different users. However, users had saved cookies that used the old method, which introduced a cookie mismatch when they visited www.catlin.edu and had a saved cookie for catlin.edu. I still don’t understand why the browser didn’t just save a new cookie when they logged in instead of silently failing.

Clearing cookies resolved the problem for individual users, but I needed a solution that would work for off-campus users with saved cookies. Ultimately, I followed the release announcement and set $cookie_domain to “.catlin.edu” so that it would work whether the user’s saved cookie was for www.catlin.edu or .catlin.edu. It also means that developers are automatically logged into our development and test sites, but we can always use a separate browser when needed.

The site log showed no errors, but one could see a series of “new session for user …” entries when a user was having problems logging in. The normal behavior is that the user successfully opens a new session then either ends the session soon thereafter or leaves it open.