2013-07-18 5 views
2

Я просто потратил впустую несколько часов без реального решения, вот в чем проблема: Я вхожу в администратор Django и сразу или после нескольких щелчков меня выбрасывает.Процессы uWSGI теряют сеансы Django

Я искал какое-то время во всех настройках и настройках. Единственный ключ до сих пор от uwsgi лог-файлов, например:

www.example.com [pid: 20047|app: 0|req: 1120/2060] 217.9.101.34() {42 vars in 841 bytes} [Thu Jul 18 15:27:35 2013] GET /admin/ => ... 
www.example.com [pid: 20047|app: 0|req: 1122/2063] 217.9.101.34() {40 vars in 786 bytes} [Thu Jul 18 15:27:37 2013] GET /admin/auth/ => ... 
www.example.com [pid: 20047|app: 0|req: 1124/2066] 217.9.101.34() {40 vars in 801 bytes} [Thu Jul 18 15:27:39 2013] GET /admin/auth/user/ => ... 
www.example.com [pid: 20047|app: 0|req: 1125/2067] 217.9.101.34() {40 vars in 740 bytes} [Thu Jul 18 15:27:39 2013] GET /admin/jsi18n/ => ... 
www.example.com [pid: 19082|app: 0|req: 947/2072] 217.9.101.34() {42 vars in 841 bytes} [Thu Jul 18 15:27:41 2013] GET /admin/ => ... 
www.example.com [pid: 20047|app: 0|req: 1128/2081] 217.9.101.34() {42 vars in 841 bytes} [Thu Jul 18 15:27:44 2013] GET /admin/auth/ 

Первые несколько запросов имеют одинаковый идентификатор процесса, который где я вошел в Тогда другой процесс берет на мой следующий запрос и, видимо, это. процесс не знает о моей сессии, и я вышел из системы. Следующий запрос снова имеет исходный идентификатор, но мой cookie уже был сброшен.

Я уже пробовал все: настройка проекта снова, настройка uwsgi config снова, проверка nginx, перезапуск всего, но ничего не помогает. Это также не может быть ошибкой cookie, поскольку она отображается в нескольких браузерах на нескольких компьютерах. В конце концов, файлы cookie устанавливаются, и сеанс регистрируется в базе данных.

стек Django 1.5.1, Python 2.7, virtualenv, Buildout, MySQL 5.5, Nginx, uwsgi, Ubuntu 12.04

Любые идеи?

Edit:

Это uwsgi конфигурации:

[uwsgi] 
#vhost = true # tried to see if that helps 
plugins = python 
socket = /tmp/example.com.sock 
master = true 
enable-threads = true 
processes = 8 
cheaper = 2 
max-requests=1000 
reload-on-rss=110 
vacuum=True 
harakiri=20 
buffer-size=16384 # added to try if that helps 
wsgi-file = /var/www/blabla/.../django.wsgi 
virtualenv = /var/www/blabla 
chdir = /var/www/blabla/... 
touch-reload = /var/www/blabla/.../django.wsgi 
+0

Используйте gunicorn. Самое лучшее, что есть. –

+0

Вы делаете что-то особенное с проверкой подлинности или промежуточным программным обеспечением в своем приложении Django или просто стандартным материалом? –

+0

@ DanielRoseman просто стандартный материал, он также работал на меня в течение нескольких дней, пока другие пользователи жаловались, и теперь при тестировании я часто получаю эту ошибку ... – webjunkie

ответ

2

по умолчанию, Джанго хранит сессии в базе данных, поэтому ваша проблема, скорее всего, из-за этой ошибки: https://code.djangoproject.com/ticket/20537

рассмотреть возможность обновления до uwsgi> = 1.2.6

2

Проверяли ли вы SESSION_ENGINE? например, если вы настроили его на использование кэширования django и установили его в locmem: // у вас возникнут такие проблемы

Другая проблема (возможно, даже если это трудно) (если вы находитесь в --lazy/- -lazy-apps) может быть процессом со старой копией кода, попробовали ли вы перезагрузить весь экземпляр?

+0

Я не изменил SESSION_ENGINE по умолчанию. Я также пытался включить или выключить ленивый режим, чтобы убедиться, что это что-то делает, но это не так. Я также остановил все процессы uwsgi и начал их несколько раз. – webjunkie

+0

, что имя хоста перед каждой логарифмией немного подозрительно: вы находитесь в режиме виртуального хостинга? если да, возможно ли загрузить приложение по требованию? если да, уверены ли вы, что все ваши модули совместимы с несколькими переводчиками? – roberto

+0

Что вы подразумеваете под спросом? Я просто устанавливаю конфигурацию uwsgi и запускаю сервис uwsgi. – webjunkie