… или почему на некоторых хостингах сессии долго не живут.

Использование ini_set(‘session.gc_maxlifetime’, value); в коде приложения отнюдь не гарантирует сессиям долгую жизнь. Устанавливая эту директиву, вы лишь обеспечиваете, что garbage collector, запущенный из вашего приложения будет  удалять во временной папке сессии, ориентируясь на это время.

Если же garbage был запущен из другого скрипта со своими или дефолтными настройками, он будет удалять файлы, естественно, не оглядываясь на параметр из первого абзаца.

Пример. Вы установили в своем main приложении время жизни сессии 7 дней. Garbage, инициированный вашим приложением, заходит и удаляет все файл старше семи дней.

Но тут вы запускаете на этом же сервере скрипт rebuildDatabase.php, у которого этих настроек нет и берутся дефолтные из php.ini: 1 день. И срабатывает GC. В лучшем случае он удалит все сессии, которые должны были жить несколько дней. В худшем — повесит весь сервер если файлов на удаление оказалось очень много.

Так что на хостинге, где на одном сервере крутится много сайтов и администраторы не позаботились о разделении папок сессий, не редки ситуации, когда изменение  session.gc_maxlifetime просто не работает, т.к. кто-то другой поставил его меньше и постоянно выкашивает ваши сессии.

Мораль: используя в своем проекте ini_set(‘session.gc_maxlifetime’, value), всегда меняйте дефолтную папку вызовом ini_set(‘session.save_path’, value). Ну и про глюки garbage collector php не забываем.