Почему Debian очищает php-сессии с помощью задания cron вместо использования встроенного сборщика мусора в php?

26

Debian и производные (Ubuntu) не используют сборщик мусора в php-сессии

session.gc_probability = 0

вместо этого они используют cron /etc/cron.d/php5

09,39 * * * * root [ -x /usr/lib/php5/maxlifetime ] && [ -d /var/lib/php5 ] && find /var/lib/php5/ -depth -mindepth 1 -maxdepth 1 -type f -cmin +$(/usr/lib/php5/maxlifetime) ! -execdir fuser -s {} 2>/dev/null \; -delete

Почему Debian решил сделать это?

— nulll
источник

29

Потому что Debian устанавливает очень строгие разрешения /var/lib/php5(1733, владелец root, группа root), чтобы предотвратить перехват сеанса PHP. К сожалению, это также препятствует работе нативного сборщика мусора сеанса PHP, потому что он не может видеть там файлы сеанса. Задание cron запускается от имени пользователя root, который имеет достаточный доступ для просмотра и очистки файлов сеанса.

Изменить : Вспомогательная документация: Поведение было установлено в ответ на ошибку # 267720 . (Раньше в стоковом php.iniфайле были комментарии об этом, но я не вижу их там сейчас в моей установке PHP на основе wheezy.)

— asciiphil
источник

Разрешает / var / lib / php5 ar drwx-wx-wt (root-root), поэтому пользователь apache может записать содержимое dir (sticky-бит), но не может его прочитать. Поэтому я понимаю, что сборщик мусора в php не сможет оценить время файлов сеанса, поэтому он не может выбрать, какие файлы будут удалены ... Я прав?

— nulll

Да, это правильно.

— Асифил

5

Вероятно, он будет немного более надежным на сайтах с низким трафиком (если вы получаете только пару сотен обращений в день, а GC запускает каждую тысячу или около того, сеансы могут длиться дольше, чем следовало бы), и я думаю, что это может быть немного менее суровым на сервере, чем родной GC, если у вас много сеансов.

— ceejayoz
источник