Ошибки работы с PHP сессиями в Unix/Linux
Ошибки работы с PHP сессиями в Unix/Linux
Хочу описать статью с возможными ошибками работы PHP и сессиями в Unix/Linux. Думаю многие сталкиваются и будет полезно знать как решать ту, или иную ошибку.
Обновлял заббикс и после его обновления, перестал корректно работать, посмотрел лог и увидел:
2017/12/08 21:15:48 [error] 40014#40014: *395 FastCGI sent in stderr: "PHP message: PHP Warning: require_once(/etc/zabbix/web/maintenance.inc.php): failed to open stream: Permission denied in /usr/share/zabbix/include/classes/core/ZBase.php on line 269
-=== Ошибка 1 ===-
Можно увидить следующую ошибку:
Cannot start session without errors, please check errors given in your PHP and/or webserver log file and configure your PHP installation properly. Also ensure that cookies are enabled in your browser.
Возникла у меня при установке phpmyadmin.
Так же, если имеется cPanel, может возникнуть такая же ошибка, я описывал решение в моей статье:
ошибка в phpMyAdmin «Cannot start session without errors»
-=== Ошибка 2 ===-
При работе с апачем, я получил:
Warning: session_start() [function. session-start]: open(/var/lib/php/session/sess_eqbchncji8kj22f0iqa9g3v7u2, O_RDWR) failed: Permission denied (13) in /var/www/vhosts/httpdocs/index.php on line 6 Warning: Unknown: open(/var/lib/php/session/sess_eqbchncji8kj22f0iqa9g3v7u2, O_RDWR) failed: Permission denied (13) in Unknown on line 0 Warning: Unknown: Failed to write session data (files). Please verify that the current setting of session.save_path is correct (/var/lib/php/session) in Unknown on line 0
-=== Ошибка 3 ===-
Получил еще ошибку:
FastCGI sent in stderr: “PHP message: PHP Warning: Unknown: Failed to write session data (files). Please verify that the current setting of session.save_path is correct (/var/lib/php/session) in Unknown on line 0” while reading upstream, client: 37.***.***.56, server: rtfm.co.ua, request: “POST /wp-admin/admin-ajax.php HTTP/1.1”, upstream: “fastcgi://127.0.0.1:9009”, host: “rtfm.co.ua”, referrer: “http://linux-notes.org/wp-admin/post.php?post=5496&action=edit&message=10”
Другие ошибки я буду добавлять по мере их возникновения.
Решения ошибок работы с PHP сессиями в Unix/Linux
Ну что, пришли к решению. Первое что необходимо сделать, — так проверить путь куда сохраняются сессии, для этого, выполните:
$ php -i |grep save_path session.save_path => /var/lib/php/session => /var/lib/php/session
Как видно у меня этот путь рассположен в /var/lib/php/session директории.
Проверим права на данную директорию:
# ls -alh /var/lib/php/session
Смотрим от какого юзера идет выполнение php кода:
# ps aux |grep php-fpm
PS: Или, можно зайти в ваш пул php-fpm и найти пользователя от которого он запущен!
Решение довольно примитивное. Для начала, стоит создать папку под использующие сессии (если ее нет еще) и выставить права:
# mkdir /var/lib/php/session # chmod 1777 /var/lib/php/session
И так же, выставляем владельца и группу:
# chown root:www /var/lib/php/session # chown -R www: /var/cache/nginx
ИЛИ:
# chmod o+rw /var/lib/php/session
Потом, открываем ваш php. ini и находим строку:
;session.save_path = "/tmp"
И нужно выполнить расскоменчивание данной строки.
PS: Возможно, нужно будет выставить права и владельца!
Если вы используете выделенные пулы под свои php- проекты, то стоит поискать данную строку в:
# grep -lR 'php_value' /etc/php-fpm.d
Если покажет файлы, то стоит посмотреть привести к:
[...] php_value[session.save_handler] = files php_value[session.save_path] = /var/lib/php/session [...]
Перезапускаем php-fpm службу:
# service php-fpm restart
Для апача, следуюет указать следующие строки:
php_value session.save_handler "files" php_value session.save_path "/var/lib/php/session"
а поиск файла можно сделать так:
# grep -lR 'php_value' /etc/
И тоже, выполнить перезапуск службы:
# service httpd restart
Вот и все решение! А у меня на этом статья «Ошибки работы с PHP сессиями в Unix/Linux» завершена.
Установка phpmyadmin. Error during session start | PHPClub
STELIO
Новичок
- #1
Привет. Не могу установить phpmyadmin. Пишет «Error during session start; please check your PHP and/or webserver log file and configure your PHP installation properly. Also ensure that cookies are enabled in your browser.». В браузере куки включены. Вроде php.ini и httpd.conf правильно настроил. Есть Сэнсэй, кто подскажет в чем проблема? php.ini http://hastebin.com/ojofaveriz.vhdl httpd.conf http://hastebin.com/egebefagah.apache
С.
Продвинутый новичок
- #2
www.adminer.org
STELIO
Новичок
- #3
С.
Продвинутый новичок
- #4
phpmyadmin — это смердящий динозавр из прошлого столетия. Его палкой трогать противно, не то что php.ini под него править.
AnrDaemon
Продвинутый новичок
- #5
Предложите адекватную замену.
С.
Продвинутый новичок
- #6
Тему не читай, комментарии пиши.AnrDaemon написал(а):
Предложите адекватную замену.
Нажмите для раскрытия…
fixxxer
К.О.
- #7
Sequel Pro, SQLYog итдAnrDaemon написал(а):
Предложите адекватную замену.
Нажмите для раскрытия…
c0dex
web.dev 2002-…
- #8
был неплохой workbench раньше, как сейчас он я хз
fixxxer
К.О.
- #9
c0dex, макосовщина как раз опенсорсная (желающие могут портировать UI на какой-нибудь Qt, хе-хе). Хорошего OSS кроссплатформенного решения я не знаю, но, впрочем, в 99% случаев мне хватает обычного консольного клиента, Sequel Pro в основном использую для ознакомления с какой-то базой неизвестной мне структуры.
флоппик
promotor fidei
- #10
c0dex
web.dev 2002-…
- #11
fixxxer, макосьовщина это макосовщина, и потому нафик) ты workbench смотрел?
флоппик
promotor fidei
- #12
Воркбенч — тормозное убогое говно, зато умеет почти все для MySQL
c0dex
web.
dev 2002-…
- #13
флоппик, пока юзаю у меня тормозов не замечено.
fixxxer
К.О.
- #14
c0dex, он какой-то неудобный и страшный. По крайней мере 2 года назад таким был, судя по скринам, мало что изменилось. Я когда на линукс-десктопе работал, SQLYog в wine запускал, и то удобнее =)
c0dex
web.dev 2002-…
- #15
ну не знаю, сейчас он выглядит очень даже привлекательно, это на убунте 14.04. На дебиане не ставил.
AnrDaemon
Продвинутый новичок
- #16
Вынужден согласиться с обоими утверждениями.флоппик написал(а):
Воркбенч — тормозное убогое говно, зато умеет почти все для MySQL
Нажмите для раскрытия. ..
Лучший способ исправить — Предупреждение PHP session.save_path не задано
Предупреждение: неизвестно: не удалось записать данные сеанса (файлы). Предупреждение PHP session.save_path не задано.
Убедитесь, что текущая настройка session.save_path верна (/tmp) в строке Unknown 0
Это сообщение об ошибке, которое наш клиент недавно получил при доступе к своему веб-сайту.
Обычно эта ошибка возникает из-за неправильных настроек директивы PHP session.save_path.
Мы в Bobcares часто получаем запросы на исправление ошибок сеанса PHP в рамках наших служб управления сервером.
Сегодня давайте рассмотрим ошибку и посмотрим, как ее исправят наши инженеры службы поддержки.
Что такое PHP Warning session.save_path не установлена ошибка?
Основная функция файла сеанса PHP — сделать данные доступными на различных страницах всего веб-сайта.
Это простой способ хранения данных для отдельных пользователей.
Если получаем ошибку значит проблема с session.save_path Конфигурация и сеансы работать не будут.
Недавно один из наших клиентов связался с нами с этой ошибкой PHP Warning session.save_path not set при доступе к содержимому его веб-сайта.
Типичная ошибка была такой:
Ошибка указывала на то, что session.save_path настроен неправильно.
Как узнать, что PHP Warning session.save_path не установлен на сервере?
Узнать session.save path значение, установленное на сервере, мы делаем следующие шаги.
1. Сначала заходим на сервер.
2. Затем мы проверяем, установлен ли на сервере session.save_path . Для этого мы создаем файл в любом текстовом редакторе и называем его phpinfo.php .
пример: vi phpinfo.php (добавьте код ниже в этот файл)
Затем мы сохраняем файл phpinfo. php.
3. Затем мы загружаем этот файл на сайт клиента, а затем открываем его в веб-браузерах по ссылке http://yourwebsite.com/phpinfo.php
4. После этого мы ищем запись, которая гласит: session.save_path , как показано ниже.
В значении директивы session.save_path есть нет значения , значит session.save_path не настроен и сеансы работать не будут.
Итак, нам нужно обновить путь сохранения сеанса в файле php.ini.
Как исправить ошибку PHP Warning session.save_path not set?
До сих пор мы обсуждали ошибку сеанса php. Теперь давайте посмотрим, как наши инженеры службы поддержки исправят эту ошибку для наших клиентов.
session.save_path — это директива PHP, которую необходимо установить в настройках конфигурации PHP (файл php.ini).
Чтобы исправить ошибку, делаем следующие шаги.
1. Логинимся на сервер.
2. Затем мы проверяем используемый обработчик PHP. Например, на серверах cPanel мы используем
/usr/local/cpanel/bin/rebuild_phpconf --current
3. Мы получаем вывод, как показано ниже.
Доступные обработчики: dso cgi нет
PHP ПО УМОЛЧАНИЮ: 5
PHP4 SAPI: нет
PHP5 SAPI: дсо
SUEXEC: включено
Включение пути сохранения сеанса зависит от типа обработчика PHP. Давайте посмотрим на точные шаги для DSO и SuPHP.
Вариант 1: обработчик PHP — DSO (с использованием файла .htaccess)
1. Если обработчик — dso , то мы переходим к корневому документу пользователя.
2. Затем мы создаем временный каталог с именем /tmp с разрешением 777 в папке веб-сайта.
Пример:
[#root@server#:cd /home/username/public_html]
(корень)> ll |grep tmp
drwxrwxrwx 2 p9r11734 p9r11734 23552 12 окт 09:08 tmp
[#root@server#/home/username/public_html]
3. После этого открываем файл .htaccess и добавляем в него следующие строки .
php_value session.save_path /home/username/public_html/tmp
4. Сохраняем и выходим из файла.
5. Затем мы проверяем это, используя информационную страницу PHP и ищем session.save_path . Если он показывает /home/username/public_html/tmp, , то мы убеждаемся, что указали правильный путь.
Вариант 2: обработчик PHP – suphp (с использованием файла php.ini)
Аналогично, если обработчиком PHP является suphp, , мы выполняем следующие шаги.
1. Создаем кастомный php.ini внутри веб-сайта.
vi /etc/php.ini
2. Добавьте запись для session.save_path в /home/username/public_html/tmp в этом файле php. ini файл.
3. Затем мы сохраняем и выходим из файла.
Это исправляет ошибку PHP Warning session.save_path not set для наших клиентов.
[Нужна дополнительная помощь в PHP Warning session.save_path не установлена ошибка? Мы исправим это для вас.]
Заключение
Короче говоря, ошибка сеанса php возникает из-за того, что в директиве session.save_path или session.save_path не задано значение. Сегодня мы увидели, как наши инженеры службы поддержки исправляют эту ошибку для наших клиентов.
ПРЕДОТВРАТИТЕ СБОЙ СЕРВЕРА!
Никогда больше не теряйте клиентов из-за низкой скорости сервера! Позвольте нам помочь вам.
Наши специалисты по серверам будут контролировать и обслуживать ваш сервер 24/7, чтобы он оставался молниеносно быстрым и безопасным.
НАЧАТЬ
var google_conversion_label = «owonCMyG5nEQ0aD71QM»;сеансов PHP с Memcached | Codementor
Вы когда-нибудь задумывались или сталкивались с требованием хранить PHP-сессии в Memcached? Хранилище в памяти, предоставляемое Memcached, делает его идеальным кандидатом для хранения сеансов PHP. Прочтите, чтобы узнать, как настроить PHP для использования Memcached в качестве хранилища сеансов.
Нам потребовалось общее хранилище сеансов для нашего приложения, развернутого на AWS. В распространенном сценарии развертывания AWS трафик направляется на несколько экземпляров EC2 через Application Load Balancer (ALB). Обычно мы используем функцию «липкости», предоставляемую целевыми группами. Он отлично работает, если у вас есть один домен. Пользователь всегда перенаправляется на тот же сервер, где хранятся его данные сеанса. Но у нашего приложения есть 3 домена, которые используют общий логин. С несколькими доменами и правилами маршрутизации ALB не может перенаправлять пользователей на один и тот же экземпляр EC2. Таким образом, пользователь не будет каждый раз приземляться на один и тот же сервер и будет выходить из системы, если попадет на другой сервер. Из-за зависимости от экземпляра EC2 мы не можем масштабировать наше приложение.
Итак, нам нужно общее хранилище сеансов, независимое от инстансов EC2. Для этого мы решили использовать сервис Elasticache. Мы создали кластер Memcached для хранения сессий и настроили PHP для использования его в качестве хранилища сессий. Мы ожидали, что это будет прямое упражнение, поскольку ранее мы использовали Memcached для кэширования динамических данных. Мы изменили следующие конфигурации PHP.
/etc/php-7.0.ini
session.save_path = "xxxxxx.ksoqsc.cfg.usw1.cache.amazonaws.com:11211"
Используйте здесь конечную точку кластера Memcached.
session.save_handler = memcached
/etc/httpd/conf.d/php.conf
Мы обнаружили, что настройки, которые мы изменили в php-7.0.ini, перезаписываются настройками в php.conf. Поэтому мы закомментировали путь сохранения сеанса и переопределения обработчика, как показано ниже.
#php_value session.save_handler "файлы" #php_value session.save_path "/var/lib/php/7.0/session"
Однако всегда бывают сюрпризы. После переноса сессий в Memcached это начало сказываться на скорости нашего сайта. Некоторые страницы, использующие сеансы, стали очень медленными. После некоторых исследований в Интернете мы обнаружили, что для решения этой проблемы необходимо настроить несколько параметров PHP.
/etc/php-7.0.ini
session.lazy_write = Off
Если установлено значение On, это означает, что данные сеанса перезаписываются только в случае их изменения.
/etc/php.d/50-memcached.ini
memcached.sess_locking = Off
Когда блокировка включена, файл сеанса блокируется для чтения/записи во время выполнения скрипта. Блокировка снимается, когда выполнение скрипта завершается.
После отключения lazy_write и sess_locking наш сайт вернулся к нормальной скорости. Как упоминалось выше, эти настройки существуют по уважительным причинам. Но их отключение никак не сказалось на нашем сайте. Для большинства веб-сайтов их можно отключить.