Dlaczego Debian czyści sesje php za pomocą zadania cron zamiast korzystać z wbudowanego modułu śmieciowego php?

26

Debian i pochodne (Ubuntu) nie używają modułu śmieciowego sesji php

session.gc_probability = 0

zamiast tego używają crona /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

Dlaczego Debian postanowił to zrobić?

ubuntu php debian garbage-collecting nulll
źródło

Odpowiedzi:

29

Ponieważ Debian ustawia bardzo rygorystyczne uprawnienia /var/lib/php5(1733, root użytkownika, root grupy), aby zapobiec przejęciu sesji PHP. Niestety uniemożliwia to także działanie modułu śmieciowego sesji natywnego PHP, ponieważ nie widzi tam plików sesji. Zadanie cron działa jako root, który ma wystarczający dostęp do przeglądania i czyszczenia plików sesji.

Edycja : Dokumentacja pomocnicza : Zachowanie zostało ustalone w odpowiedzi na błąd nr 267720 . (Kiedyś w php.inipliku zapasowym były komentarze na ten temat, ale nie widzę ich teraz w mojej instalacji PHP opartej na wheezy.)

asciiphil
źródło
Perms on / var / lib / php5 ar drwx-wx-wt (root-root), więc użytkownik Apache może napisać zawartość katalogu (lepki bit), ale nie może jej odczytać. Rozumiem więc, że moduł śmieciowy php nie będzie w stanie ocenić plików sesji, więc nie może wybrać, które pliki mają zostać usunięte ... mam rację?
nulll
Tak, to jest poprawne.
asciiphil
5

Prawdopodobnie będzie nieco bardziej niezawodny w witrynach o niskim natężeniu ruchu (jeśli otrzymujesz tylko kilkaset odsłon dziennie, a GC strzela tylko co tysiąc, sesje mogą trwać dłużej niż powinny) i wyobrażam sobie, że może to być trochę mniej surowe na serwerze niż natywna GC, jeśli masz dużo sesji.

ceejayoz
źródło