Я надеялся, что кто-нибудь даст мне совет, пожалуйста. Я использую сервер CentOS 6, и за последние пару дней объем моего диска увеличился с 60 до 135 ГБ (98% заполнено). Я считаю, что проблема может быть связана с каталогом сеанса PHP (/ var / lib / php / session), поскольку он кажется огромным (я не могу ls или rm), в этом каталоге должны быть буквально миллионы файлов.
Как мне удалить этот каталог? rm здесь не работает, и я также пытался заменить rsync пустым каталогом, но это тоже занимает вечность.
Если это вызывает проблему - почему PHP не удаляет эти файлы автоматически?
Есть ли где-нибудь запись в журнале, которая укажет мне направление эксплойта, DDOS или сбоя?
Спасибо
sudo find /var/lib/php/session -type f -delete будет работать лучше чем sudo rm /var/lib/php/session/* из-за расширения * вряд ли возможно для больших списков файлов.
Похоже, ваше приложение создает сеансы, но никогда их не уничтожает. Это может быть плохое программирование и сочетание плохих настроек среды.
Если вы хотите удалить эти файлы сеанса, вам нужно использовать sudo, поскольку они, скорее всего, не принадлежат вашему пользователю.
sudo rm /var/lib/php/session/*
я буду не удалить весь каталог сеанса.
Другое дело - настроить тайм-аут сеанса PHP на меньший интервал.
Конфигурация Ubuntu по умолчанию такова, что PHP не истекает срок действия сеансов, но есть задание cron, которое удаляет старые файлы. Полное обсуждение этого займет некоторое время (ИМХО, это очень плохая идея), однако я не знаю, что Redhat применяет аналогичный подход.
Вы не предоставили никаких подробностей о конфигурации вашего сеанса. Эта ситуация может возникнуть из-за значений для любого из session.gc_probability, session.gc_divisor или session.gc_maxlifetime. Установка значений по умолчанию 1, 100 и 1440 должна обеспечить разумную гомеостатическую систему. как только вы очистите файлы, как описано в других ответах.
Вы не сказали, сколько одновременных сеансов вы видите в своей системе, их средний размер или файловую систему, в которой они хранятся. Если вы ожидаете более 300 сеансов (в зависимости от файловой системы), вам следует подумать об использовании дерева каталогов, а не одного каталога для хранения файлов; префикс session.save_path на 1 или 2 (при условии, что это не сервер NFS, поддерживающий кластер серверов, и в этом случае вам следует перейти на другую архитектуру).
Мэтт упоминает, что это может быть конфигурация selinux. Если это позволяет создавать файлы, но никогда не удалять. Хотя это возможно, это предполагает, что конфигурация в системе серьезно испорчена. В этом случае (проверьте журнал аудита) вам, вероятно, следует выполнить чистую установку и восстановить приложение поверх нее.
Маловероятно, что это связано с плохим программированием.