Excluindo arquivos de sessão PHP expirados no Ubuntu 14.04

Question

Tudo começou com o MySQL não sendo capaz de iniciar.

Após algumas pesquisas na web, descobri que o servidor ficou sem inodes.

df -i

Filesystem     Inodes  IUsed  IFree IUse% Mounted on
/dev/simfs     500000 500000      0  100% /
none           131072     56 131016    1% /dev
none           131072      1 131071    1% /sys/fs/cgroup
none           131072     63 131009    1% /run
none           131072      4 131068    1% /run/lock
none           131072      1 131071    1% /run/shm
none           131072      1 131071    1% /run/user

O google me levou a supor que os arquivos de sessão do PHP nunca são deletados ... o que parece ser verdade porque executar ls php5 | wc -l me dá 424669 !

Eu li que o PHP.ini session.gc_probability é definido como 0 por padrão e que o ubuntu lida com a limpeza através do cronjob /etc/cron.d/php5.

/etc/cron.d/php5

# /etc/cron.d/php5: crontab fragment for php5
#  This purges session files older than X, where X is defined in seconds
#  as the largest value of session.gc_maxlifetime from all your php.ini
#  files, or 24 minutes if not defined.  See /usr/lib/php5/maxlifetime

#Look for and purge old sessions every 30 minutes
09,39 *     * * *     root   [ -x /usr/lib/php5/maxlifetime ] && [ -x /usr/lib/php5/sessionclean ] && [ -d /var/lib/php5 ] && /usr/lib/php5/sessionclean /var/lib/php5 $(/usr/lib/php5/maxlifetime)

Isso parece correto, então por que esse script não está funcionando? Existe uma maneira de eu confirmar que isso é realmente executado a cada 30 minutos?

    

Answer 1

PHP session files never get deleted

Você não diz qual manipulador de sessão está usando - supondo que seja o padrão, as sessões expiradas devem ser limpas sempre que a coleta de lixo da sessão for acionada. Você tem session.cache_expire muito alto e / ou session.gc_probability muito baixo, e / ou session.gc_divisor muito alto.

session.gc_probability is set to 0 by default

Não - somente nos sistemas Debian (o Ubuntu é derivado do Debian). Alguém no Debian acha que ter permissões estranhas no armazenamento de sessões impede as sessões de hi-jacking. Na verdade, ele lida apenas com um subconjunto muito restrito de possíveis ataques - e quando você coloca as medidas apropriadas para lidar com os vetores de ataque mais prováveis, o problema desaparece.

Uma conseqüência disso é que você precisa de acesso root se quiser gerenciar suas sessões de PHP de qualquer outra forma diferente daquela que foi pré-determinada pelo Debian.

Na maioria das vezes eu gosto do Debian - mas isso sempre me pareceu um tanto bobo.

    

Answer 2

Você poderia escrever para o syslog usando o comando Logger desde sua execução como Root.

& & logger -t PHP_SESSIONS "Sessões PHP limpas"

depois " cat / var / log / syslog | grep PHP_SESSIONS " mais tarde para ver as horas que ele foi executado.

É claro que isso indica que o cron job foi executado e não se foi bem-sucedido.