Posted by nonsie on June 5, 2009 at 5:08pm
| Project: | Session API |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | bug report |
| Priority: | critical |
| Assigned: | Unassigned |
| Status: | needs review |
Issue Summary
I keep on running into duplicate entry errors for session_api on our site - there doesn't seem to be any pattern to it though.
Duplicate entry 'c3ae9b7e3189caa4b436278a69515676' for key 2 query: INSERT INTO session_api (session_id) VALUES ('c3ae9b7e3189caa4b436278a69515676') in /includes/common.inc on line 3422.In most cases it happens not not logged in users and we have normal Drupal caching turned on. I think it's related to cron not doing the cleanup that was reported in another issue and is fixed in the dev version.
Comments
#1
nonsie, were you ever able to get a fix for this issue. We're seeing the same problem over here.
Our current hypothesis is that this is an issue with running multi-site, or possibly just multiple versions of Drupal on the same machine.
#2
Hello,
On the Forgot Password page, after entering an email and clicking Request new password, I am getting the below error every time:
user warning: Duplicate entry '8e6a107842dc2aab476c1b74f4efa362' for key 'session_id' query: UPDATE session_api SET session_id = '8e6a107842dc2aab476c1b74f4efa362' WHERE sid = 118 in /srv/www/example.com/public_html/includes/common.inc on line 3477.I would say this issue is critical? Can anyone please assist!
Thank you
#3
time() is not unique enough. perhaps microtime() is better.
#4
ok, here is a patch to test it.
#5
found a better way.
#6
sorry wrong patch ;-)
this is faster than @foo();.
#7
@tobiasb
i looked into your patches, my question is now:
are these pathces to look whether the changed lines are the point of trouble or are they to fix the problem?
the patch in #6 seems to some kind of diagnotic, while #5 looks like an atempt to solve the problem.
I didn't try any of these because i do not know which to take.
I'm having the duplicated entrys and want to get rid of them.
#1: I'm not running multiple Drupal installs or an multisite on the machine where i'm having this error messages
#8
#6 is the cleaner way as #5. and it is a fix to avoid the warning message.
#9
Patch in #6 worked for me to get rid of the errors (Thank you tobiasb!). I manually applied it to 6.x-1.4.
#10
I get the same errors:
Duplicate entry 'c5b78520117fe1ea3cf33fad0e6eac5d' for key 'session_id' query: INSERT INTO session_api (session_id) VALUES ('c5b78520117fe1ea3cf33fad0e6eac5d') in /var/www/clients/client94/site244/docroot/includes/common.inc in Zeile 3538.I'm not quite sure why and when this is happening. Visitors reported them to appear occasionally and I myself could only reproduce it a few times (while randomly surfin around). Since the provided patches simply turn off the error messages for that case I didn't use the patch – I just put the error_reporting exclusively to the log. Yet this floods the log quite a bit.
I might have a deeper look into this next week.
#11
The duplicate key error comes from the database table session_api which defines the column session_id as unique key which, however, is not generated in unique way in session_api.module line 49:
<?php$session_id = md5(ip_address() . time() . drupal_get_private_key());
?>
None of those components is unique enough, so it's very probable that the session_id will be the equal for two or more visitors. There should actually be a random component which would make the session_id distinct from each other.
EDIT: Let's consider we run this module in a higher traffic site for a while, the log is flooded with error messages, we roll-out a patched version fixing the session-id issue, but why there's still errors coming to the log? That's because there's still plenty of those not-so-unique session-id:s around stored in browsers, and if the cookie life-time wasn't set lower by configuration they will live for 30 days, unless the visitor returns to site more often and the cookie is renewed and the same session-id. It will live until visitor's browser cookies are cleared... To get totally rid of error messages we would need to roll-out a patched version that regenerates the session-id if inserting the cookie-originated session-id fails.
#12
Given that I don't really want visitors sharing sessions, I've patched my copy of the module to use microtime() concatenated with rand() instead of time() for the session ID generating code. Will see if this stops the random stream of "duplicate entry" errors.
In fact, given that I now am using rand(), I probably don't need the drupal_get_private_key() or ip_address() calls...
#13
This didn't in fact reduce the number of errors, so I've reverted to the standard code, that just uses time().
#14
We are also experiencing this error. Do the patches above only disable the error message, or do they actually resolve the problem?
Thanks
Mike
#15
subscribing
#16
I'm guessing that okaalto's Edit in #11 is part of the problem, and why the microtime() patch in #4 doesn't immediately work.
Otherwise, I'd guess that a patch like #4 and/or a randomizing aspect suggested in #12 would do the trick.
#17
That's what I thought, but even with microtime() and rand() to generate the unique string to hash I was still getting duplicates. The only way that could be possible is, I think, if we ended up with duplicate md5 hashes, but that's extremely unlikely.
How can we get to the point of trying to re-insert a session ID that we've already generated? Is there a race condition, where two separate browser requests run almost at the same time?
Perhaps the order of setting cookies, checking cookies, and INSERTing a new session_id needs to be re-arranged?
#18
Here is a question.... What update has caused this? For our site, this error has only just begun filling our logs. I can't remember when/what it was that I updated a module that caused these errors to start.
We are having issues with Views versions 2.14 and 2.15 not working (version 2.16 resolved it) and also content on our site is being blocked from anonymous views (such as our Decisions voting module), all of these issues only coming about over the last few weeks.
Crazy
Mike
#19
Anyone actually resolved this issue yet? I started getting these errors today using 6.x-1.4