Обнаружена проблема с работой php сессий на вашем сервере что делать
PHP: Самые распространенные проблемы при работе с сессиями
Записная книжка рассеянного [в пространстве и времени] программиста
PHP: Самые распространенные проблемы при работе с сессиями
С сессиями в php существует множество непонятных проблем. С появлением виртуальных окружений проблем стало больше.
Рассмотрим наиболее часто встречающиеся проблемы сессий на файлах (мы не будем затрагивать сессии в бд и кастомные обработчики).
session_start(): open(filename, O_RDWR) failed: No such file or directory
Очевидно, что ошибка возникает, когда не существует пути, по которому пишутся данные. Но при этом вы знаете, что на диске каталог, который был указан как аргумент session_save_path(), существует.
Вы увидите на экране или в логах ошибку из заголовка (не во всех дистрибутивах).
Можно посмотреть audit.log из selinux, но если там нет ничего подозрительного и каталог действительно есть (а вы его создали выше), то причина такого поведения достаточно неожиданна.
Происходит это потому что вы работаете в centos 7 версии (или redhat\fedora) и выше. Именно в этой версии ввели параметр PrivateTmp для сервисов. Что это означает для нас?
Сделайте второй скрипт, который перечисляет содержимое директории /tmp, а так же выводит реальный путь каталога /tmp/sessions.
Как это побороть? Использовать другой каталог для хранения сессий. Или перед стартом приложения проверять и создавать в случае необходимости нужную файловую структуру.
session_start(): Session data file is not created by your uid
Не самая распространенная ошибка. Чаще всего возникает в виртуальных окружениях.
Ошибка возникает в случае, когда uid владельца файла сессии не совпадает с uid текущего пользователя под которым запущен интерпретатор.
Как проверить, что это именно наш случай? Нужно создать скрипт, которыый создает файл в каталоге, в котором вы планируете размещать сессии и сверяет uid владельца файла и uid владельца процесса.
Если мы увидим false, то да. Проблема имеет мысто быть. И вам нужно переместить сессии в другое место.
Так же подобное поведение характерно при некоторых способах монтирования nfs.
session_start(): open(filename, O_RDWR) failed: Permission denied
Каталог недоступен для записи и достаточно дать права 777. Но тут не все так очевидно и данный трюк действует не всегда. Если вы работаете в дистрибутивах, которые используют selinux, то даже при установке полных прав система можем вам не позволить писать по выбранному пути.
Это происходит потому что контекст процесса отличается от контекста папки. Вы всегда можете посмотреть в /var/log/audit/audit.log чтобы убедиться.
Как обращаться с контекстами можно подробнее посмотреть в документации и в книге.
Литература
RSS feed This page was generated by GitHub Pages.
Обнаружена проблема с работой php сессий на вашем сервере что делать
БлогNot. PHP: 12 причин, по которым не работают сессии
PHP: 12 причин, по которым не работают сессии
Хотя PHP последних версий стал работать с сессиями гораздо лучше, начинающие (а порой и опытные) программисты всё ещё нередко мучаются с ними, особенно если речь идёт об адаптации старого кода к новым версиям. В этой заметке я собрал самые распространённые причины, по которым могут не работать сессии (авторизация не выполняется, вход на сайт происходит только со второго раза и т.п.)
Сначала разумные причины:
1. Сессия не запущена.
Лучше всего вызывать session_start сразу после открывающего тега
Я часто в запутанном коде из множества модулей делаю это в виде
Есть смысл также запускать сессию только из модуля с функциями, подключаемыми к каждой странице сайта кодом вроде этого:
2. Сессия или её данные удаляются из кода раньше, чем должны использоваться.
3. Хранилище сессии недоступно для записи.
4. Данные сессии не записываются после отправки заголовка.
5. В браузере не включены Cookies.
Механизм куки-файлов необходим для работы сессий. Проверьте, что куки разрешены в браузере.
6. В коде или настройках сайта происходит редирект с одного домена на другой.
При редиректе сессия потеряется, даже если это редирект с site.com на www.site.com или наоборот.
7. Некорректная работа со временем в скрипте.
Скрипт имеет тысячу и один способ использовать время, отличающееся от серверного, в том числе, ставить время для куки и т.п.
А что если в момент создания кука оказывается уже просроченной?
8. Устаревшие функции сессий.
Мне сегодня помог п. 4 при «реанимации» работающего «со второго входа» сайтега.
Теперь причины более экзотические, которых, вроде бы, не должно быть, а они случаются.
9. На сайте нет файла favicon.ico или favicon.png
Некоторым бразуерам (Chrome) на некоторых серверах (nginx) это может помешать работе с сессиями, хотя понятных причин я назвать не могу.
10. У вас в файле кодировка UTF-8 с меткой BOM.
Избавьтесь от неё. Хотя, по идее, вы должны были увидеть раньше популярнейшее предупреждение (warning) «headers already sent» (см. по ссылке). Но бывает, что не усмотрел директивы отключения варнингов где-нибудь в недрах кода. Кстати, включите контроль всех ошибок при работе.
Что тут сказать? Избавьтесь от них.
12. Так легла карта.
Скорее всего, сессия просто стартует не там, где Вы думаете.
Блокировка PHP сессий
Что такое сессии в PHP
Технология сессии в PHP являются простым способом хранения информации для отдельно взятого пользователя сайта. Например: товары, добавленные в корзину магазина, настройки уведомлений и т.д. При первом запросе сайта к серверу, в браузере сохраняется в cookies уникальный идентификатор сессии пользователя. Затем идентификатор или связка идентификатора с IP адресом идентифицирует пользователя. Это может использоваться для сохранения состояния между запросами страниц. Идентификаторы сессий обычно отправляются браузеру через сессионный Cookie и используются для получения имеющихся данных сессии.
По умолчанию PHP использует внутренний обработчик files для сохранения сессий, который установлен в INI-переменной session.save_handler. Этот обработчик сохраняет данные на сервере в директории, указанной в конфигурационной директиве session.save_path.
Самый простой пример использования сессии, например, вывод количества обращений к странице для каждого пользователя:
Пример работы скрипта можно посмотреть по адресу https://beget.com/session_test.php.
Каким способом возможна блокировка сессий
На сайте php в секции описания работы сессий есть примечание (http://php.net/manual/ru/session.examples.basic.php):
Сессии, использующие файлы (по умолчанию в PHP), блокируют файл сессии сразу при открытии сессии функцией session_start() или косвенно при указании session.auto_start. После блокировки, ни один другой скрипт не может получить доступ к этому же файлу сессии, пока он не будет закрыт или при завершении скрипта или при вызове функции session_write_close().
Скорее всего это станет проблемой для сайтов, которые активно используют AJAX и делают несколько одновременных запросов. Простейшим путем решить эту проблему будет вызов функции session_write_close() сразу же как только все требуемые изменения в сессии будут сделаны, предпочтительно ближе к началу работы скрипта. Также можно использовать другой механизм сессии, который поддерживает конкурентный доступ.
В последнее время проблема блокирования сессий становится всё более частой. Отчасти это связано с усложнением сайтов и необходимостью производить больше вычислений на строне сервера, а так же с большим распространением AJAX. К сожалению, не всегда логика приложения, особенно если она сложная, позволяет эффективно ограничить время блокировки конкурирующих за сессию процессов. Ситуация усугубляется еще тем, что 3-5 подобных клиентов способны быстро забить зависшими и простаивающими в ожидании процессами PHP-воркеры, в результате чего сайт начнёт выдавать 5XX ошибку.
Самый простой пример блокировки сессий:
Если открыть этот файл сначала в первой вкладке, а потом во второй — вторая вкладка будет ждать, пока не доработает первая. То есть фактически вторая вкладка будет дожидаться, пока первая не освободит файл сессии (что занимает в конкретном случае 30 секунд). Данная проблема хорошо описана в блоге компании 1С-Битрикс на Habrahabr.
Какие варианты решения данной проблемы существуют
Для хранения сессий можно использовать БД, такие как MySQL или PostgreSQL (что не совсем правильно, учитывая возможности большинства БД и возможную скорость работы в данной задаче), Memcached (не гарантирует хранение сессии, возможно ее удаление) и Redis, который мы считаем оптимальным хранилищем. По скорости он не уступает Memcached, но при этом может гарантировать сохранность данных.
Обнаружена проблема с работой php сессий на вашем сервере что делать
Российский суд наложил на Meta оборотный штраф в 1,9 млрд рублей
Маркетологу «под елочку»: 20 вредных советов, как все угробить и начать новый год с фэйлов
В течение последних десяти суток ваши сайты не отвечали 13 секунд из-за блокировки сессий в PHP.
Это не бегет случайно? Проверьте логи, может нашествие ботов.
Вот почитайте, что они сами говорят на этот счет /ru/forum/970360
Хостинг по цене героина. Достался по наследству интернет-магазин с посещаемостью 700-800, это сообщение у меня висело всегда, пока не свалил от туда. Там еще есть куча всяких ограничений.
Можно просто забить. Выключи подсказку если мешает. Это не баг, а скорее фишка.
В отличии от Бигет, другие хостеры просто об этом молчат. То есть это не означает что на них ваш магазин как-то лучше работает. Но вы конечно можете так думать и спать спокойнее))
Обычная практика при использование Cloudlinux.
Выбирать между 13 секундами за «10-ки» суток или использовать другие где нет жестоких ограничениях и при высокой нагрузке ложатся «все клиенты» решать ТС, но я б посмотрел варианты в сторону ВПС.
treshnyuk, бегет не использует CloudLinux
😂 Вот что случается, когда хостер делает «прозрачность» для клиентов, которые не понимают о чем речь.
это исключительно архитектурные проблемы скрипта, если могут возникать ситуации блокировок
сессии не стоит просто на каждый чих запускать, и по возможности сбрасывать на диск с помощью session_write_cache();
Либо использовать свои обёртки, типа сессии в mysql/redis/memcache и т.д.
Зависание скриптов из-за блокировки сессий в PHP
Одна из самых странных «багофич» PHP выражается тем, что при определённых условиях становится невозможным запуск одного и того же скрипта (или даже разных скриптов) одновременно несколько раз на одном и том же сервере.
Все более-менее опытные программисты знают, что в PHP есть встроенный механизм хранения данных между запросами, который называется «сессиями».
Суть оного (если кто не знает) находится под спойлером.
Баг (а точнее, особенность) стандартных сессий PHP заключается в том, что файл, в котором хранятся данные сессии, на время работы скрипта блокируется для доступа. Это делается не случайно, а умышленно, чтобы в результате перезаписи файла каким-то другим скриптом его данные не потерялись.
А на практике это выражается тем, что физически невозможно отправить на одновременную обработку два скрипта с одним и тем же идентификатором сессии. Как только один скрипт запустился и открыл сессию (с помощью session_start() или же сессия открылась автоматически — есть опция в php.ini), так сразу эта сессия становится недоступной для других скриптов (причём это может быть вторая копия этого же скрипта) и при попытке открыть сессию они просто зависают на неопределённое время, а именно — до того момента как завершится первый скрипт или произойдёт таймаут.
Такой же точно эффект может проявляться в том случае, если из одного скрипта вы пытаетесь делать вызов другого скрипта этого же сайта. В этом случае вызванный скрипт натыкается на блокировку доступа к сессии и зависает на строке session_start(), а первый скрипт, вызвавший его, тоже зависает, поскольку ждёт ответа от второго, вызванного, скрипта.
И теперь, когда вы знаете в чём заключается проблема, вы наверняка уже поняли, как обходить подобные ситуации. Ну а для тех, кто не догадался, я привожу ряд решений, или даже правильнее сказать, правил, как следует поступать, чтобы не попасть в ловушку.
Правило номер 1.
Не используйте сессии, если в этом нет необходимости. Например, если скрипт предназначен для запуска из cron, в нём совершенно не обязательно открывать сессию через session_start(), поскольку вы всё равно не сможете передать куку, содержащую SID.
Правило номер 2.
Делайте скрипты, использующие сессию, максимально шустрыми и простыми. Идея заключается в том, чтобы у пользователя не возникло желания нажать другую ссылку, пока открывается первая. Если он это успеет сделать, то второй скрипт зависнет в ожидании окончания выполнения первого скрипта и пользователю придётся ждать ещё дольше, пока он в конце концов не покинет сайт.
Правило номер 3.
Старайтесь не вызывать из своих скриптов страниц своего же сайта. Я имею ввиду вещи вроде
Или же, если это необходимо, закрывайте сессию перед вызовом, а затем снова её открывайте. Примерно вот так:
Правило номер 4.
PHP позволяет переопределять механизм хранения сессий на свой собственный. Например, можно хранить данные не в файле, а в базе данных или даже в оперативной памяти (используя memcached). В ближайших статьях я об этом напишу.
Подписывайтесь на мой блог и будьте в курсе!
[subscribe2]