Проблеми з PHP 5.3 та папкою сесій


81

Нещодавно я перейшов на PHP 5.3, і з тих пір я отримую (спорадичні) повідомлення про помилки, які свідчать про те, що Apache (або може бути очищувачем файлів сеансів) не має дозволів на папку, де зберігаються сеанси.
Це трапляється випадковим чином і не може бути відтворено з точними кроками, що змусило мене здогадатися, що це засіб для очищення сеансу.
Хтось має досвід таких помилок?

Повідомлення про помилку (яке запускається на session_start()лінії):

ps_files_cleanup_dir: помилка opendir (/ var / lib / php5): дозвіл відхилено.

ls -ltr у каталозі сеансу дає:

drwx-wx-wt  2 root          root          4096 2010-05-25 12:39 php5

Усередині цього каталогу я бачу файли сеансів, що належать www-data, що є моїм Apache, і додаток працює нормально. Що мене здивує, під яким користувачем працює сеанс GC?


Я зробив, але не на 5.3. Виявилося, що помилка дозволів відфільтрована до шляху збереження сеансу. Припускаю, ви перевірили дозволи?
Джаррод Кропива

@Jarrod Я бачу, що www-дані можуть читати та писати в цю папку (в якій зараз є w & r для всіх, користувача, групи та світу), чи слід перевіряти щось інше?
Itay Moav -Malimovka

Я здогадуюсь, що причина, що це трапляється епізодично, полягає в тому, що помилка виникає під час запуску збирача сміття сеансу, який, на мою думку, за замовчуванням має 1% шансів запуску за ініціалізацію сесії. Чи вносили ви зміни до php.ini щодо сесій? Що тут не за замовчуванням? Перевірте власника папки сеансу, після чого я втратив себе, не бачачи .ini або помилок.
Джаррод Кропива

Власник є root, сеанси створюються за допомогою www-data, кожен має доступ до цієї папки. Я перегляну налаштування ini по одному, шукаю щось підозріле.
Itay Moav -Malimovka

ps_files_cleanup_dir: помилка opendir (/ var / lib / php5): Дозвіл відмовлено (
Itay Moav -Malimovka

Відповіді:


121

Виправлення: У вашому php.iniнаборі session.gc_probabilityдля0

Причиною, я вважаю, що я знайшов відповідь тут http://somethingemporium.com/2007/06/obscure-error-with-php5-on-debian-ubuntu-session-phpini-garbage

По суті, збирання сміття налаштовано на виконання завдань cron у деяких системах (тобто Ubuntu / Debian). Деякі виконувані файли php ini, такі як php-cli, також намагаються робити збір сміття, і це призводить до помилки, яку ви отримали.


6
Я також маю цю проблему в Ubuntu 10.04, але після перевірки php.ini я знайшов, що session.gc_probabilityвже встановлено 0.
Джонатан

5
@Jonathan - Ви, мабуть, виявите, що тоді ваша програма встановлює значення.
SynackSA

3
@SynackSA Як не дивно, це коли я створити власний, сайт конкретний файл php.ini, що, коли session.gc_probabilityспускові до 1. Це відбулося навіть тоді , коли немає ніяких налаштувань у файлі php.ini б то ні було ! Я використовую suphp на Ubuntu, Apache 2.2. Цікаво, чи це якась помилка. У будь-якому випадку, додавання session.gc_probability = 0до мого користувацького, специфічного для сайту файлу php.ini, здається, вирішує проблему.
Джонатан

2
@Jonathan Так слід передбачати роботу, оскільки значення за замовчуванням - 1
ROunofF

2
Це відключає сеансовий збір сміття. Можливо, вам слід перевірити, чи насправді є cron, що очищає ваші сеанси.
відмовився

23

Здається, це типова помилка на серверах Ubuntu (я використовую Lucid LTS). Існують стандартні дозволи для каталогу / var / lib / php5

drwx-wx-wt  2 root     root     4096 2011-11-04 02:09 php5

тому веб-сервер може писати, але не читати, я думаю, це пояснює помилки.

Оскільки Ubuntu має власне прибирання сміття за допомогою cron ( /etc/cron.d/php5), можливо, найкраще відключити збір сміття php, як запропоновано вище Diwant Vaidya.

session.gc_probability = 0

Насправді є причина, чому папка сеансу не повинна бути доступною для читання у всьому світі - як сказано в Посібнику PHP :

Якщо ви залишите цей набір у доступному для читання каталозі, наприклад / tmp (за замовчуванням), інші користувачі на сервері можуть перехопити сеанси, отримавши список файлів у цьому каталозі.


2

Рішення, яке я використовую в даний час (але я не впевнений, що воно правильне), полягає у наданні права власності на папку сеансу користувачеві Apache (у моєму випадку www-дані).


2
Як зазначала Марі вище, це може створити проблему безпеки для будь-якого робочого сервера.
Kzqai

2
Я вже давно застосував правильне рішення :-) Але, проблема безпеки здебільшого полягає у спільних серверах
Itay Moav -Malimovka

1
Очищенням сесії @pike займається php cli через CRON
Itay Moav -Malimovka

1

Це питання мене хвилює вже деякий час. Я змінив значення, як запропоновано у php.ini, і проблема постійно виникала. Я знайшов те саме значення конфігурації у своєму index.php, а також private / Zend / session.php. Тож варто заглянути трохи глибше, якщо проблема постійно виникає. Сподіваюся, це комусь корисно.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.