We have a standard drupal 4.5.2 install package which is behaving strangely on a particular server platform (W2K sp4 with restrictive network security setup???) but fine elsewhere.
Drupal sessions are getting randomly logged out - ie. you browse around some pages logged in as some auth user, and after a while (sometimes just one or two pages, sometimes many) you'll be presented with your login box again.
It's not browser or client dependent (tried IE6, Firefox 1.0.4, either directly from the drupal server or from a remote client PC). And no changes to our std install which appears fine on all other platforms (other W2K, W2003, solaris, hpux) we've tried, nor changes to our standard php.ini file other than local SMTP setup (which works OK).
You can see in the browser 'view cookies' that the PHP PHPSESSID cookie is persisting just fine throughout with a fixed sessionid, but at a random point (maybe drupal session.inc garbage collection???) drupal loses/deletes the login userid. If you watch drupal's {sessions} table in MySQL you see it reset the userid from some non-zero value to a zero value, with nothing else appearing to change, e.g.:
before (uid, sessionid, hostid, timestamp, session object):
7, '0de91733de556480976cb626a0336ffa', '192.168.0.4', 1117140376, 'messages|a:0:{}'
after:
0, '0de91733de556480976cb626a0336ffa', '192.168.0.4', 1117140414, 'messages|a:0:{}'
The difference in timestamps isn't enough for a PHP timeout
(php.ini::[Session]session.gc_maxlifetime = 1440)
I'm stumped - any ideas?
Comments
too short
increase that gc_maxlifetime. it is much too short. it is in seconds. here are drupal's current recommendations:
ini_set('arg_separator.output', '&');
ini_set('magic_quotes_runtime', 0);
ini_set('magic_quotes_sybase', 0);
ini_set('session.cache_expire', 200000);
ini_set('session.cache_limiter', 'none');
ini_set('session.cookie_lifetime', 2000000);
ini_set('session.gc_maxlifetime', 200000);
ini_set('session.save_handler', 'user');
ini_set('session.use_only_cookies', 1);
ini_set('session.use_trans_sid', 0);
poormanscron problem
Note to self - when having two strange problems concurrently, they are probably related...
I added a bunch of logging to drupal's PHP session hooks, and eventually discovered what is going on. The PHP session starts and end each time the user makes a request for a page from their browser. e.g. you have an initial PHP session as a guest, then when you submit your login details you get another PHP session which starts as guest but ends as your logged in user. It shares state (like your user id etc) between requests using a PHPSESSION cookie on your client.
We have poormanscron configured to run every minute, I guess at the end of a user request. And on inspection of the logs it looks like POP email access is actually working (see attached screenshot with log messages about 'comment: unauthorized comment submitted ...'). However given the POP account is external and is an existing mailbox containing about 500 messages, my guess is that the poormans cron hook is running at least the allotted minute each time [I'm not sure if mailhandler will partially process the mailbox for a minute and then carry on next time, or simply fail and starts at the beginning each time?].
So what happens is that you view the portal homepage (as guest) and poormanscron kicks off at the end of your request (leaving that PHP session active). Then you submit login details and view a page as (say) admin user, which starts and ends a PHP session as that new user, saving your admin id to the {sessions} table to pick up next time. This works fine until the original poormanscron session finishes (which was running as guest) since it then writes back the session state (including the 'guest' user id) to the {sessions} table. Now when you next visit a page, you appear to have been logged out.
As a workaround I've changed poormanscron to run every 10m which I think significantly improves things.
But seems like there is a real problem here with the session containing poormanscron overwriting the session state of a later request when it finishes its allotted execution time.
Bug logged
See http://drupal.org/node/24001