18

While working in the Craft admin area, on a fresh install, I get logged out every once in a while. It makes the CMS unusable.

I have tried:

  1. Clearing cookies
  2. Resetting the cache in the backend

Sometimes it logs out after 1 pageview, sometimes after 10.

I am using a Macbook Pro, 10.9.3 Mavericks. This happens in both Chrome and Safari (haven't tried Firefox).

I am running Vagrant with: PHP 5.5.12, Ubunutu 14.04, Nginx. Accessing the project locally via http://project.craft.dev

Has anyone experienced something similar? Are there any error logs for this kind of thing?

Update: in the craft.log I get a few errors:

2014/07/11 19:38:56 [trace] [system.db.CDbCommand] Querying SQL: SELECT count(`id`) FROM `craft_tasks` WHERE (level = 0) AND (status = :status). Bound with :status='error' 
in /vagrant/dlfm/craft/craft/app/etc/db/DbCommand.php (79) 
in /vagrant/dlfm/craft/craft/app/services/TasksService.php (420) 
in /vagrant/dlfm/craft/craft/app/controllers/TasksController.php (57)

and

2014/07/11 19:38:55 [error] [php] session_write_close(): Failed to write session data (files). Please verify that the current setting of session.save_path is correct (/vagrant/dlfm/craft/craft/storage/runtime/sessions/) (/vagrant/dlfm/craft/craft/app/services/HttpRequestService.php:852)
Stack trace:
#0 /vagrant/dlfm/craft/craft/app/framework/web/actions/CInlineAction.php(49): Craft\TasksController->actionRunPendingTasks()
#1 /vagrant/dlfm/craft/craft/app/framework/web/CController.php(308): CInlineAction->runWithParams()
#2 /vagrant/dlfm/craft/craft/app/framework/web/CController.php(286): Craft\TasksController->runAction()
#3 /vagrant/dlfm/craft/craft/app/framework/web/CController.php(265): Craft\TasksController->runActionWithFilters()
#4 /vagrant/dlfm/craft/craft/app/framework/web/CWebApplication.php(282): Craft\TasksController->run()
#5 /vagrant/dlfm/craft/craft/app/etc/web/WebApp.php(863): Craft\WebApp->runController()
#6 /vagrant/dlfm/craft/craft/app/etc/web/WebApp.php(252): Craft\WebApp->_processActionRequest()
#7 /vagrant/dlfm/craft/craft/app/framework/base/CApplication.php(180): Craft\WebApp->processRequest()
#8 /vagrant/dlfm/craft/craft/app/index.php(196): Craft\WebApp->run()
#9 /vagrant/dlfm/craft/public/index.php(14): require_once()
REQUEST_URI=/index.php/admin/actions/tasks/runPendingTasks
in /vagrant/dlfm/craft/craft/app/services/HttpRequestService.php (852)
in /vagrant/dlfm/craft/craft/app/controllers/TasksController.php (37)
in /vagrant/dlfm/craft/craft/app/etc/web/WebApp.php (863)

but this one looks most suspect:

24. 2014/07/11 19:41:47 [error] [application] Tried to restore session from a cookie, but the given login name does not match the given uid. UID: 9d515b08-1073-4872-a0e2-155c389a2991 and loginName: Jason.

24. 2014/07/11 19:41:47 [error] [application] Tried to restore session from a cookie, but the given hashed database token value does not appear to belong to the given login name. Hashed db value: 37bb858b4b13b688c4034fe5eb127f75f4931387czozNjoiNDBlNTk0YWQtNGYxZS00NjAxLWEwY2UtZDJlY2NhNDkwMmQ1Ijs= and loginName: Jason.
in /vagrant/dlfm/craft/craft/app/services/UserSessionService.php (797)
in /vagrant/dlfm/craft/craft/app/services/UserSessionService.php (64)
in /vagrant/dlfm/craft/craft/app/etc/web/WebApp.php (592)
Improve this question
5
  • You can check /admin/utils/logs, if you're logged in of course.
    – Matt Stein
    Commented Jul 11, 2014 at 19:17
  • That's just a shortcut to your craft/storage/runtime/logs folder. The reason you're getting logged out should be in there.
    – Brad Bell ♦
    Commented Jul 11, 2014 at 19:18
  • What should I look for in here? I don't see any errors, just a long list of what is being loaded or queried.
    – Jason D
    Commented Jul 11, 2014 at 19:27
  • @JasonD Did I see you find the problem in today's Craft chat? If so, please add your answer for posterity! :)
    – Matt Stein
    Commented Jul 11, 2014 at 23:36
  • @MattStein, thanks for your help on the chat! Unfortunately I am still experiencing this problem... I will add an answer as soon as I get one. For anyone else that ends up here: the current guess (that we had in the chat) is it's a Nginx/Vagrant issue not giving PHP the correct permissions to write the session data to craft/storage/runtime/sessions
    – Jason D
    Commented Jul 12, 2014 at 18:24

9 Answers 9

Reset to default
26

My solution is to add:

'overridePhpSessionLocation' => false

Into craft/config/general.php

This tells Craft to use the default location to write sessions, instead of craft/storage/runtime/sessions

For whatever reason, even though craft/storage/runtime/sessions has CHMOD 777, PHP was saving the session file with 644. When it tried to write to the same file again, it got and error and logged me out.

I also (unsuccessfully) tried giving PHP ownership of the folder, which should in theory fix the problem too.

 sudo chown -R www-data:www-data sessions
 chown: www-data: illegal group name

I am assuming it's a Vagrant/OSX thing.

Improve this answer
7
  • Ahh... nice catch. I had forgotten about that config setting. It was originally added because some edge case hosts were doing crazy things like storing PHP session in memcache.
    – Brad Bell ♦
    Commented Jul 13, 2014 at 0:52
  • don't forget to mark your answer as correct :)
    – Tyler Willingham
    Commented Jul 13, 2014 at 1:01
  • Nice job tracking this down, Jason!
    – Matt Stein
    Commented Jul 13, 2014 at 20:55
  • I was running into the same problem when I enabled NFS on Vagrant, and this answer fixed it. Thanks!
    – mohd4482
    Commented Aug 18, 2014 at 9:42
  • 1
    Did you try the 'overridePhpSessionLocation' => false setting? Notice PHP is not capitalized. The setting used to work with PHP in all caps (recently it started happening again until @BradBell figured it out).
    – Jason D
    Commented Oct 9, 2014 at 13:54
4

These are the steps that solved the problem for me (PHP 5.4 , Nginx):

  • Delete the contents of craft/storage/runtime
  • Set the correct file permissions
  • Added 'overridePhpSessionLocation' => true, to the site configuration
Improve this answer
4

For me the solution required was

'requireMatchingUserAgentForSession' => false in my config/general.php

I was debugging the site in Chrome and it was changing my user agent, which was instantly logging me out.

Improve this answer
3

For us, we had the same problem but a different root cause.

We noticed that we were getting multiple new session files created for each request, all with the same data in them. After a bit of digging, I noticed session.auto_start was On in php.ini, so tried turning it Off.

And that fixed it, no more surplus session files been created on disk, and no random logging out.

So make sure that php.ini has 

session.auto_start = 0
Improve this answer
2

Check if you can write in /vagrant/dlfm/craft/craft/storage/runtime/sessions/. There is where the sessions are being stored. To test, try chmod 777 -R /vagrant/dlfm/craft/craft/storage/runtime/sessions and try again. Those permissions are too wide, but if this works after you might know the cause.

Improve this answer
2
  • I double-checked /storage and /storage/* and they're at 777, and the problem is continues to happen..
    – Jason D
    Commented Jul 11, 2014 at 20:41
  • I dont think this is related to Craft but to your Vagrant configuration, where you mount the shared folder into the VM. Can you post your Vagrantfile here? I created this VM provisiones with Ansible and is the one we are using to develop Craft, feel free to test it: github.com/miguelbalparda/vm
    – mbalparda
    Commented Jul 13, 2014 at 10:13
2

Here's more on PHP sessions & Craft if it helps:

The Case of the Missing PHP Session

Improve this answer
1

I've had the same problem for the past few weeks with my windows vagrant setup, it's been driving me crazy. Works fine on our staging server.

I think I finally got it working :)

I did 2 things not sure yet which fixed it:

  1. added this to my vagrant file config.vm.synced_folder "./craft/storage/runtime", "/var/www/craft/storage/runtime", disabled: true

  2. destroyed my vagrant instance (vagrant destroy) and recreated it (vagrant up)

Improve this answer
1
  • Nah still having problems, but I have narrowed it down... When I first setup my vagrant instance it all works fine,then after a few hours craft admin starts complaining that cUrl is not installed (I guess it's trying to check for updates), so I install cUrl and that's when I start having problems, the sessions files don't write and the only fix I can find is to destroy my instance and start again
    – Andrew Wisener
    Commented Oct 24, 2014 at 0:47
1

OK I have a definite answer to this issue this time...

The problem is caused because craft fails to write out the session files in /craft/storage/runtime/sessions, if you look in there you will see zero byte files :(

The issue seems to be because of vagrant/virtual box syncing files between the host and my pc. So the trick is to get vagrant not to sync the sessions folder. For me this was not that easy, it seems that if you sync the /craft folder it syncs all subfolders even if you tell it not to (by creating another sync and disabling it). So I had to explicitly state which craft folders to sync - ugh! It works which is great, but I am predicting trouble down the track if craft adds another folder to it's top level structure.

Anyway here is what I put in my vagrant file to get it work

config.vm.synced_folder "./public", "/var/www/public", :mount_options => ['dmode=777', 'fmode=777']
config.vm.synced_folder "./craft/app", "/var/www/craft/app", :mount_options => ['dmode=777', 'fmode=777']
config.vm.synced_folder "./craft/plugins", "/var/www/craft/plugins", :mount_options => ['dmode=777', 'fmode=777']
config.vm.synced_folder "./craft/config", "/var/www/craft/config", :mount_options => ['dmode=777', 'fmode=777']
config.vm.synced_folder "./craft/templates", "/var/www/craft/templates", :mount_options => ['dmode=777', 'fmode=777']
config.vm.synced_folder "./craft/storage/backups", "/var/www/craft/storage/backups", :mount_options => ['dmode=777', 'fmode=777']
config.vm.synced_folder "./craft/storage/userphotos", "/var/www/craft/storage/userphotos", :mount_options => ['dmode=777', 'fmode=777']
config.vm.synced_folder "./craft/storage/runtime/assets", "/var/www/craft/storage/runtime/assets", :mount_options => ['dmode=777', 'fmode=777']
config.vm.synced_folder "./craft/storage/runtime/cache", "/var/www/craft/storage/runtime/cache", :mount_options => ['dmode=777', 'fmode=777']
config.vm.synced_folder "./craft/storage/runtime/compiled_templates", "/var/www/craft/storage/runtime/compiled_templates", :mount_options => ['dmode=777',

'fmode=777'] config.vm.synced_folder "./craft/storage/runtime/logs", "/var/www/craft/storage/runtime/logs", :mount_options => ['dmode=777', 'fmode=777'] config.vm.synced_folder "./craft/storage/runtime/state", "/var/www/craft/storage/runtime/state", :mount_options => ['dmode=777', 'fmode=777'] config.vm.synced_folder "./craft/storage/runtime/temp", "/var/www/craft/storage/runtime/temp", :mount_options => ['dmode=777', 'fmode=777']

Improve this answer
1

My solution was to run:

sudo chown -R ec2-user /var/lib/php/session/

Obviously your mileage would vary depending on your setup

Improve this answer

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.