Приветствую
Мудл версии 2.8.7 и 2.9+
На том и на другом если обновить страницы несколько раз(иногда два иногда три раза) то происходит логаут.
Временно решается очисткой кэша( Purge all caches ).
Раньше сидели на 2,5, такой проблемы не наблюдалось. Кэши чистили, можно сказать чисто от делать нечего, в раз несколько месяц.
Кто нибудь сталкивался с такой проблемой? Как это победить?
/admin/settings.php?section=sessionhandling
тут настройки смотрели?
да смотрел, там все по умолчанию кроме sessiontimeout = 4 часа
хранение в базе данных включено? или нет? попробуйте этот пункт поменять
Хранение сессии в базе выключено.
Включил, понаблюдаем теперь.
Хранение сессии в базе выключено.
Включил, понаблюдаем теперь.
Не помогло, проблема остается.
Как вариант - проверьте доп плагины, есть к примеру auth_uniquelogin который может выкинуть если меняется устройство или ip. Кроме этого в одних из последних обновлениях такую же функцию встраивали в основное ядро программы (local плагины смотрите).
Указанных вами плагина нет. Локальных тоже, по крайней мере если перейти к разделу /admin/localplugins.php показывает сообщение
Проверьте тут параметр /admin/settings.php?section=manageauths
Больше у меня нет идей
Firebug показывает это в перменной MoodleSession
Каой размер сессии показывает Firebug? И сейчас где сессии хранятся?
Чистка кэша к сессиям никакого отношения не имеет, иначе бы каждого админа при очистке кэша выкидывало с сайта принудительно.
При чистке кэша увеличивается свободное место в папке moodledata, отсюда смею предположить банальную нехваку места на диске при хранении сессии в файловой системе. Сессии будут создаваться нулевого размера. Сталкивался с таким.
Если сессии хранятся в базе, таблицы не должны быть в MyISAM. См. настройки сессий в файле config-dist.php
Размеры 39 байт,
Данный момент сессии хранятся в файлах.
До этого несколько дней был на базе для эксперимента. База Oracle 11g
Мест на диске достаточно.
Посмотрите, сколько файлов у вас в moodledata/sessions. Если слишком много, значит что-то не так. За регулярную автоматическую очистку старых сессий отвечает cron. Убедитесь, что он у вас настроен на ежеминутный запуск.
На всякий случай проверьте права на папку с сессиями. Проверьте состояние жесткого диска, может он у вас сбоит? Проверьте состояние файловой системы. Много места на диске - это ещё не показатель. У меня несколько раз было, что большое количество мелких файлов не давало писать на диск, хотя внешне казалось, что на диске ещё несколько гигабайт свободного места.
Проверьте время на сервере. Может быть у вас неправильно идут часы и из-за этого браузер удаляет cookie раньше времени.
Не настраивали ли вы firewall на блокировку слишком частых запросов? Не регулировали ли в веб-сервере число активных процессов?
Проверьте состояние параметра php session_auotostart. Должно быть 0
Файлы в moodledata/sessions нормально создаются удаляется, с утра было 339 сейчас 857.
И все свежие примерно за последние 4 часа.
Насчет session_auotostart, такого ключа вообще нет в нашем php.ini.
Там ведь должен находиться этот ключ, правильно?
Шя погуглю и добавлю в нужное место.
К статьи крон у нас настроен не на ежеминутное выполнение а каждые 15 минут.
нашел session.auto_start здесь /admin/phpinfo.php
| session.auto_start | Off | Off |
вот все настройки сессии
| Session Support | enabled |
| Registered save handlers | files user |
| Registered serializer handlers | php php_binary wddx |
| Directive | Local Value | Master Value |
|---|---|---|
| session.auto_start | Off | Off |
| session.cache_expire | 180 | 180 |
| session.cache_limiter | nocache | nocache |
| session.cookie_domain | no value | no value |
| session.cookie_httponly | Off | Off |
| session.cookie_lifetime | 0 | 0 |
| session.cookie_path | / | / |
| session.cookie_secure | Off | Off |
| session.entropy_file | /dev/urandom | /dev/urandom |
| session.entropy_length | 32 | 32 |
| session.gc_divisor | 1000 | 1000 |
| session.gc_maxlifetime | 345600 | 1440 |
| session.gc_probability | 1 | 0 |
| session.hash_bits_per_character | 5 | 5 |
| session.hash_function | 0 | 0 |
| session.name | MoodleSession | PHPSESSID |
| session.referer_check | no value | no value |
| session.save_handler | files | files |
| session.save_path | /var/www/html/moodledata/sessions | /var/lib/php5 |
| session.serialize_handler | php | php |
| session.upload_progress.cleanup | On | On |
| session.upload_progress.enabled | On | On |
| session.upload_progress.freq | 1% | 1% |
| session.upload_progress.min_freq | 1 | 1 |
| session.upload_progress.name | PHP_SESSION_UPLOAD_PROGRESS | PHP_SESSION_UPLOAD_PROGRESS |
| session.upload_progress.prefix | upload_progress_ | upload_progress_ |
| session.use_cookies | On | On |
| session.use_only_cookies | On | On |
| session.use_trans_sid | 0 | 0 |
Не совсем по делу, но. У Вас есть веские мотивы пользоваться Oracle? Это мощная база, но с рядом специфических нюансов из-за которых разработчики регулярно поднимают вопрос о том, чтобы отказаться от неё. У Вас коммерческая версия Oracle на отдельном от moodle сервере? Если у вас Oracle XE на том же сервере, что и moodle - подумайте о переезде на Postgresql.
Это был приказ начальства, два года назад с MySQL перешли на Oracle.
Там действительно есть проблемы, в нескольких местах немного меняли код после прехода, чтоб работала с Oracle
Возможно в скором времени перейдем на Postgresql. А Oracle передадим, в смысле лицензию, в другой проект, так как бюджет режут по всем проектам.
