¿Por qué Debian limpia las sesiones de php con un trabajo cron en lugar de usar el recolector de basura incorporado de php?

26

Debian y derivados (Ubuntu) no usan el recolector de basura de sesión php

session.gc_probability = 0

en su lugar usan un 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

¿Por qué Debian ha elegido hacer esto?

— nulll
fuente

29

Debido a que Debian establece permisos muy estrictos en /var/lib/php5(1733, raíz del propietario, raíz del grupo) para evitar el secuestro de sesión PHP. Desafortunadamente, esto también evita que el recolector de basura de sesión PHP nativo funcione, porque no puede ver los archivos de sesión allí. El trabajo cron se ejecuta como root, que tiene acceso suficiente para ver y limpiar los archivos de sesión.

Editar : Documentación de respaldo: El comportamiento se estableció en respuesta al error # 267720 . (Solía haber comentarios en el php.iniarchivo de acciones sobre esto, pero ahora no los veo allí en mi instalación PHP basada en wheezy).

— asciiphil
fuente

Permisos en / var / lib / php5 ar drwx-wx-wt (raíz-raíz), por lo que el usuario de apache puede escribir el contenido del directorio (bit fijo), pero no puede leerlo. Así que entiendo que el recolector de basura de php no podrá evaluar el tiempo de los archivos de sesión, por lo que no puede elegir qué archivos se eliminarán ... ¿estoy en lo cierto?

— nulll

Si eso es correcto.

— asciiphil

5

Es probable que sea un poco más confiable en sitios con poco tráfico (si solo recibe un par de cientos de visitas al día y GC solo dispara cada mil o más, las sesiones pueden durar mucho más de lo que deberían) e imagino que podría ser un un poco menos duro en el servidor que el GC nativo si tienes muchas sesiones.

— ceejayoz
fuente