Системы на основе Debian Сессия убита за 30 минут в специальном cron, как переопределить?

Question

Выдернул мои волосы, пытаясь выяснить, почему мои сеансы заканчиваются / убиваются / уничтожаются через 30 минут.Похоже, в системах на основе Debian есть специальный запущенный cron, который игнорирует все конфигурации php.ini и apache и убивает любой бездействующий сеанс за 30 минут.

Путь cron: /etc/cron.d/php5

Внутри cron:

# /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 ] && [ -d /var/lib/php5 ] && find /var/lib/php5/ -type f -cmin +$(/usr/lib/php5/maxlifetime) -print0 | xargs -n 200 -r -0 rm

Я неплохо настраиваю и настраиваю хосты, но я не sysAdmin.Может ли кто-нибудь помочь мне переопределить / отредактировать / изменить / перенастроить это, чтобы я мог установить значение дольше?Я думаю, что 3 часа было бы неплохо, но я хотел бы понять изменения, поэтому, если кто-то на более высоком уровне захочет сократить время сеанса / дольше, я обдумываю, как настроить это изменение.

Благодаря любой помощи в пониманииthis

EDIT: добавление / usr / lib / php5 / maxlifetime кода

#!/bin/sh -e

max=1440

for ini in /etc/php5/*/php.ini; do
        cur=$(sed -n -e 's/^[[:space:]]*session.gc_maxlifetime[[:space:]]*=[[:space:]]*\([0-9]\+\).*$/\1/p' $ini 2>/dev/null || true);
        [ -z "$cur" ] && cur=0
        [ "$cur" -gt "$max" ] && max=$cur
done

echo $(($max/60))

exit 0

, чтобы он выглядел, как ищущий все файлы php.ini, находит наибольшее значение, сравнивает его с 1440(что составляет 24 минуты).

Вот файлы php.ini

/etc/php5/apache2/php.ini
session.gc_maxlifetime = 1440 

/etc/php5/cgi/php.ini
session.gc_maxlifetime = 1440

/etc/php5/cli/php.ini
session.gc_maxlifetime = 1440

, но почему мой сеанс сценария прерывается на 30, а не на 24 минутах?

РЕДАКТИРОВАТЬ # 2: CRON, работающий каждые 30 минут, поэтому сеанс выглядит убитым с 30-минутными интервалами.Но это также может занять от 24 до 54 минут, FYI

Также просматривая код в: /usr/lib/php5/maxlifetime он принимает самое высокое значение, и во время моего тестирования я пытался снизить порог, чтобы ускорить состояние.

Похоже, мне просто нужно увеличить один файл php.ini до более чем одного часа тестового теста.

Answer 1

Редактировать файл /usr/lib/php5/maxlifetime

Значение должно быть в секундах. Этот файл на самом деле также проверит ваш php.ini, поэтому я не знаю, почему он не работает для вас.

Answer 2

Это вопрос к serverfault.com.

Однако измените session.gc_maxlifetime в /etc/php5/apache2/php.ini или - если у вас нет apache2 одного - одного из других /etc/php5/*/php.ini файлов.Затем сценарий /usr/lib/php5/maxlifetime будет использовать максимум для этого параметра, найденного в любом из этих файлов.

Редактирование maxlifetime не поможет или, по крайней мере, только до тех пор, пока пакет php5-common не будет обновлен снова.

Answer 3

Если вы пришли сюда из-за того, что ваш cron выдает ошибки каждые 30 минут (в 09 и 39), у вас могут быть одинаковые ошибки в вашем системном журнале и / или почтовом ящике:

[ -x /usr/lib/php5/maxlifetime ] && [ -d /var/lib/php5 ] && find /var/lib/php5/ -type f -cmin +$(/usr/lib/php5/maxlifetime) -print0 | xargs -n 200 -r -0 rm
PHP Fatal error: Directive 'allow_call_time_pass_reference' is no longer available in PHP in Unknown on line 0

Возможно, причина в том, чтовы upgraded your Debian to Wheezy и у вас есть старые записи в вашем /etc/php5/apache2/php.ini.

Мне пришлось закомментировать следующие строки, и ошибки исчезли.

• allow_call_time_pass_reference
• register_long_arrays

Я пишу это, потому что это один из лучших результатов Google, если вы ищете сообщения об ошибках, и это может повлиять на многих пользователей / администраторов, которые поддерживали свои установки debian более одного выпуска.

PS: Это мне очень помогло: http://vernontbludgeon.com/blog/archives/2013/10/debian-php-session-garbage-collection-maxlifetime-fails-when-php.ini-has-obsolete-directives.html

Answer 4

Вы можете указать свой собственный сеансовый путь session.save_path ИЛИ использовать другой обработчик в целом session.save_handler

Однако вынеобходимо предоставить соответствующий механизм для управления файлами нежелательных сессий.

Обнаружил это в моем php.ini

; NOTE: If you are using the subdirectory option for storing session files
;       (see session.save_path above), then garbage collection does *not*
;       happen automatically.  You will need to do your own garbage
;       collection through a shell script, cron entry, or some other method.
;       For example, the following script would is the equivalent of
;       setting session.gc_maxlifetime to 1440 (1440 seconds = 24 minutes):
;          cd /path/to/sessions; find -cmin +24 | xargs rm

Недавно я столкнулся с этой проблемой, когда файлы нежелательных сессий накапливались, потому что я использовал PHPи mod_fcgid с пользовательским session.save_path для каждого виртуального хоста.

Answer 5

Используйте ниже cron для удаления неиспользуемых сеансов.

39 20 * * * 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) -print0 |xargs -r -0 rm

Answer 6

Это прямо в вашем фрагменте cronjob php5:

Поиск и очистка старых сессий каждые 30 минут

Не имеет значения, что сценарий удаляет 24-минутные сеансы, если сценарий невыполняется не чаще, чем каждые 30 минут:)