Por que o Debian limpa as sessões de php com um trabalho cron em vez de usar o coletor de lixo embutido do php?

26

Debian e derivados (Ubuntu) não usam o coletor de lixo da sessão php

session.gc_probability = 0

em vez disso, eles usam um 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 que o Debian escolheu fazer isso?

— nulll
fonte

29

Porque o Debian define permissões muito rigorosas em /var/lib/php5(1733, raiz do proprietário, raiz do grupo) para impedir o seqüestro de sessões do PHP. Infelizmente, isso também impede que o coletor de lixo da sessão PHP nativo funcione, porque não pode ver os arquivos da sessão. O trabalho cron é executado como root, que possui acesso suficiente para ver e limpar os arquivos da sessão.

Edit : Documentação de suporte: O comportamento foi estabelecido em resposta ao bug # 267720 . (Costumava haver comentários no php.iniarquivo de ações sobre isso, mas não os vejo lá agora na minha instalação PHP baseada em chiado).

— asciiphil
fonte

Permissões em / var / lib / php5 ou drwx-wx-wt (raiz raiz), para que o usuário do apache possa escrever o conteúdo do diretório (bit adesivo), mas não pode lê-lo. Então, eu entendo que o coletor de lixo do php não será capaz de avaliar o atime dos arquivos da sessão para que ele não possa escolher quais arquivos serão excluídos ... estou certo?

— Nulll 30/05

Sim esta correto.

— Asciiphil

5

É provável que seja um pouco mais confiável em sites com pouco tráfego (se você receber apenas algumas centenas de acessos por dia e o GC for acionado a cada mil ou mais, as sessões poderão durar muito mais do que deveriam) e imagino que seja uma pouco menos severo no servidor que o GC nativo, se você tiver muitas sessões.

— ceejayoz
fonte