2

This problem is driving me crazy and after hours of reading and trying all possible suggested solutions I feel I have to give it a go here.

We always had problem changing the backend session timeout from default 3600 to 86440 (24 hours). Just change the settings in backend/admin don't do it. Before we upgraded Magento from 1.6.2 to 1.9.1 we managed to change timeout in varien.php and php.ini.

We have changed settings in htaccess, php.ini, varien.php and in system Magento configuration now. But I still get logged out after 1 hour (3600).

What makes it even more strange is that on the same server we made the update on our dev URL, and when sure all was working we transfered the files to the live/production URL.

On the dev, the timeout is working as we want, but not on live. And the files and settings are exactly the same.

I had a Magento expert and also my server admin looking at the files, and also for them it's a mystery. Really, what's going on?!?

-- UPDATED POST WITH INFORMATION! --

Dedicated server:
DELL PowerEdge R210 II
Processor: Intel(R) Xeon(R) CPU E31220 @ 3.10GHz
RAM:2x42GB DDR3 - 1333MHz LV
Hard Disk OS: 2x256GB DELL 10000rpm - RAID 5
Operating System: CentOS 6.5 64Bit
DirectAdmin: 1.45.4
Apache: 2.4.10
MySQL: 5.6.20
PHP (mod_php): 5.3.28

E-commerce platform:
Magento CE 1.9.0.1 multistore

5
  • Please enumerate all the things you tried to avoid misunderstandings and wrong answers.
    – mbalparda
    Commented Jul 19, 2014 at 22:16
  • Run this command then post contents of /tmp/headers: curl -D /tmp/headers -o /dev/null -q http://your-production-site.example.com/. Anonymize if you must, but don't alter timestamps and cookie names.
    – user4351
    Commented Jul 20, 2014 at 5:26
  • Here is the return: HTTP/1.1 200 OK Date: Sun, 20 Jul 2014 11:44:30 GMT Server: Apache X-Powered-By: PHP/5.3.28 Set-Cookie: adminhtml=k1bptotef0og6u4sjm2ge96d44; expires=Mon, 21-Jul-2014 11:44:30 GMT; path=/ Expires: Thu, 19 Nov 1981 08:52:00 GMT Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 Pragma: no-cache X-Frame-Options: SAMEORIGIN Vary: Accept-Encoding,User-Agent Transfer-Encoding: chunked Content-Type: text/html; charset=UTF-8
    – Mats
    Commented Jul 20, 2014 at 11:49
  • In php.ini file we have added:
    – Mats
    Commented Jul 21, 2014 at 17:05
  • In php.ini file we have added: realpath_cache_ttl=86400 (ok for production site) session.gc_maxlifetime=86400 In htaccess 1 line: php_value session.gc_maxlifetime 86400 In /app/code/local/Mage/Core/Model/Session/Abstract/Varien.php: $cookie->setLifetime(86400);
    – Mats
    Commented Jul 21, 2014 at 17:07

1 Answer 1

5

So the issue is resolved Mats.

Thanks for sharing the credentials of the production server to resolve it. Now things are working perfect fine, just spoke to Mat's on the skype and he seems to be satisfied.

The issue was getting me crazy as it needs a testing of progressive hours and checking if the cookie expired on the setting in the backend.

So here is the solution if you have any. I have also listed down the debug approach I have used. you can use this approach to resolve other issues as well. So thought of covering in the single article.

  1. I observed that the two cookies were set one with the dot in front of domain and one without domain. ex. (www.domain.com and .www.domain.com). Meaning the .www.domain.com set the subdomains expires time as well but www.domain.com is stick to the doamain itself. So try applying playing with the session.cookie settings.
  2. Do not use explicit setting in the .htaccess or php.ini dedicated to your root.

If you have remove it.

php_value session.cookie_lifetime 86400

php_value session.gc_maxlifetime 86400

  1. If you have suhosin then do not forget to add these settings. basically suhosin patches the early php version securities. after php 5.4 it is not required. but if you have then add these setting in .htaccess or directly make changes in ini files.

    Suhosin PHP setttings

php_value suhosin.mail.protect 0 php_value suhosin.memory_limit 999M php_value suhosin.post.max_vars 5000 php_value suhosin.post.max_value_length 500000 php_value suhosin.request.max_vars 5000 php_value suhosin.request.max_value_length 500000 php_flag suhosin.session.cryptua off

  1. Check you memory limit. Session stores a huge data in it. Magento uses sessions extensively so must to have a large memory traces to keep the sessions at least 1G of memory is required to execute the website properly otherwise get ready to face the consequences which is unmanageable to trace.

  2. Install the vanilla magento setup in another directory and compare the core files. The idea is to verify that you should not have any changes in core. command to compare two folders with rsync DRY RUN.

    rsync -rvnc /home/public/domains/domain.com/public_html/vipul_magento/magento/app/code/core/ /home/public/domains/dev. domain.com/public_html/vipul_magento/app/code/core/ --exclude 'media' --exclude 'skin' | more

you can use sdiff command to compare the files for any changes.

  1. To debug the session and cookies put the logs in the app/code/core/Mage/Core/Model/Resource/Session.php and app/code/core/Mage/Core/Model/Session/Abstract/Varien.php. like this. //Mage::log("init lifetime:- " , null , 'vipul.log'); Mage::log("database set lifetime:- ". $this->_lifeTime , null , 'vipul.log'); On different places where you feel that magento may have wrong session time out. Don't forget to remove them when you are done.

  2. Keep check in the session file for time stamping inside the /var/session folder. generally sess_sessionid files get generated when seen ls -al it will give you time it was touched. It was really helpful in testing.

  3. If still not giving you an idea. Set the php.ini file session.gc_maxlifetime 86400 and session.cookie_lifetime 0 restart the apache2 to test again.

  4. Finally go to the magento backend Go to timezone setting in admin change the time zone to UTC and save immediately again switch back to the prefered timezone and save it. Clear the cache. These are the issue with the upgradation of the magento. so please take care if the session issues persists then you should be doing this tricks. ;). It will help and do some magic.

  5. Finally remove the php.ini local file from the root of magento and start relying on your magento settings.

Hope That works well!! TADA!!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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