Внимание, дисклеймер! Прежде чем повторять за мной всё описанное ниже — перепроверьте штатные настройки журналов сервера pfSense!
Не так давно от бдительного старины Zabbix (тег) пришло сообщение о переполнении диска на сервере с установленным pfSense. Я устало побрёл на веб-страничку самого pfSense и обнаружил вот такое:
Поиски виновника привели в каталог /var/squid/logs к файлу access.log программного прокси-сервера Squid. Кстати, у штатной тёти Вики (на окладе) про логи есть отдельная заметка.
Итак, команда du ответила, что access.log распух до 44 гигабайт и продолжал нагло поедать дисковое пространство прямо на глазах. Хороший аппетит у товарища.
Чтобы узнать размер нужного каталога, а в последствии и файла, я использовал команду du -sh /path, каждый раз закапываясь всё глубже в файловую систему, пока не остановился на этой конструкции:
du -sh /var/squid/logs/access.log
В поисках правильного метода уменьшения размера файла access.log, я, как водится, отправился в дебри официальных документаций и форумов и, к сожалению, не смог найти там решения. Ротация логов, по какой-то неведомой причине, вывела ошибку, а изкоробочные настройки pfSense отказывались помочь.
Про ошибку можно и подробнее. В pfSense в настройках пакета Squid есть блок с настройками журналирования:
Вот только после изменения поля Rotate Logs на условные 30 дней и нажатия кнопки Save — веб-морда ругнулась на прозрачный режим и отказалась сохранить настройки. В этом ещё предстоит разбираться…
А что делать с access.log? Надо же как-то привести его к приемлемым масштабам и освободить дисковое пространство. В любом случае, удалять системные файлы, которые чем-то не устраивают — занятие экстремальное. Попробуем изящнее…
…Просто снесём всё содержимое файла, объединив его с пустотой, командой cat:
cat /dev/null > /var/squid/logs/access.log
Как итог:
Вот только это далеко не конец истории…
