Фанат
Не буду ввязываться в диспут, просто я хотел узнать мнение тех, кто использовал session.gc_maxlifetime, ибо выставлять этот параметр и потом иметь непонятно почему убитые сессии мне не хочется. Но ваш ответ:
короче.
ставь гц макслайфтайм, но гарантии, что оно будет жить две недели, тебе никто не даст.
навевает сомнения в работе сборщика мусора, а именно -почему таки он не будет убивать только то, что ему положено?
Судя по той-же документации, куда меня так упорно все отправляют, все должно быть в порядке - сборщик ориентируется на дату/время модификации файла - и если с этого момента прошло больше session.gc_maxlifetime секунд - то файл киляется. На самом деле - этот механизм работает или нет? Или граблит? Две недели ждать для проверки - слишком долго, мне надо счаз сказать заказчику - типа сервер настроен и проблем не будет. Либо - в противном случае - писать скриптец и пихать его в шедулер...
-~{}~ 15.08.06 23:25:
А вот такой момент - хочу загасить вааще сессионный мусоросборщик - лучше, действительно, шедулером ночью, когда по сайту ходят только случайно заблудшие буржуины да поисковые боты (хе-хе, мечтать, типа, не вредно) - в общем - когда на сайт нагрузки почти нету - запускать скрипт убийства старых сессионных файлов. Если выставить сессионные настройки так:
session.gc_probability 0
session.gc_divisor 1
то, получается, вероятность запуска gc равна нулю.
Это загасит gc или нет?