Были ли у кого-нибудь проблемы с logrotate до того, как это заставило файл журнала повернуться, а затем вернуться к тому же размеру, который был изначально? Вот мои выводы:
Скрипт Logrotate:
/var/log/mylogfile.log {
rotate 7
daily
compress
olddir /log_archives
missingok
notifempty
copytruncate
}
Подробный вывод Logrotate:
copying /var/log/mylogfile.log to /log_archives/mylogfile.log.1 truncating /var/log/mylogfile.log compressing log with: /bin/gzip removing old log /log_archives/mylogfile.log.8.gz
Файл журнала после усечения
[root@server ~]# ls -lh /var/log/mylogfile.log -rw-rw-r-- 1 part1 part1 0 Jan 11 17:32 /var/log/mylogfile.log
Буквально через секунды:
[root@server ~]# ls -lh /var/log/mylogfile.log -rw-rw-r-- 1 part1 part1 3.5G Jan 11 17:32 /var/log/mylogfile.log
Версия RHEL:
[root@server ~]# cat /etc/redhat-release Red Hat Enterprise Linux ES release 4 (Nahant Update 4)
Версия Logrotate:
[root@DAA21529WWW370 ~]# rpm -qa | grep logrotate logrotate-3.7.1-10.RHEL4
Несколько заметок:
olddir каталог, в котором хранятся файлы журнала за каждую ночь.Вероятно, это связано с тем, что, даже если вы усекаете файл, процесс записи в файл будет продолжать запись с каким бы смещением оно ни было в конце. Итак, что происходит, logrotate обрезает файл, размер равен нулю, процесс снова записывает в файл, продолжая с того смещения, на котором он остановился, и теперь у вас есть файл с NULL-байтами до точки, в которой вы его усекли, плюс новый записи, записанные в журнал.
od -c после усечения + внезапное увеличение, сгенерированный вывод по строкам:
0000000 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
*
33255657600 \0 C K B - s e r v e r [ h t t
33255657620 <more log output>
Это говорит о том, что от смещения 0 до 33255657600 ваш файл состоит из нулевых байтов, а затем некоторых разборчивых данных. Достижение этого состояния не займет столько же времени, сколько потребовалось бы для фактической записи всех этих нулевых байтов. Файловые системы ext {2,3,4} поддерживают так называемые разреженные файлы, поэтому, если вы просматриваете область файла, которая ничего не содержит, эта область будет считаться содержащей нулевые байты и не будет занимать место. на диске. Эти нулевые байты на самом деле не будут записаны, просто предполагается, что они там есть, поэтому время, необходимое для перехода от 0 до 3,5 ГБ, не займет много времени. (Вы можете проверить, сколько времени потребуется, выполнив что-нибудь вроде dd if=${HOME}/.bashrc of=largefile.bin seek=3432343264 bs=1, это должно создать файл размером более 3 ГБ за несколько миллисекунд).
Если ты бежишь ls -ls в ваших лог-файлах после того, как они были усечены и снова внезапно увеличились, теперь он должен сообщать число в начале строки, которое представляет фактический размер (в блоках, занятых на диске), который, вероятно, на порядки меньше, чем размер сообщил только ls -l.
я чрезвычайно уверен, что Кьетил попал в нее. Дрю, возможно, вас еще не убедили его объяснения, но я призываю вас внимательно прочитать то, что он сказал.
Если вы принимаете это, исправление заключается в том, чтобы либо остановить и перезапустить приложение при ротации журналов, либо использовать такой инструмент, как apache "rotatelogs", где вы передаете выходные данные в инструмент через канал, а инструмент позаботится о время от времени ротация файла журнала. Например, один из моих экземпляров apache регистрирует
ErrorLog "|/usr/sbin/rotatelogs /www/logs/error_log 604800"
что приводит к появлению большого количества файлов журнала с такими именами, как
-rw-r--r-- 1 root root 4078 Dec 21 01:04 error_log.1292457600
-rw-r--r-- 1 root root 4472 Dec 29 08:41 error_log.1293062400
-rw-r--r-- 1 root root 78630 Jan 4 12:57 error_log.1293667200
-rw-r--r-- 1 root root 15753 Jan 12 01:10 error_log.1294272000
появиться без перезапуска apache; После этого я могу сжать их вручную. Обратите внимание, как ротация выполняется каждую неделю, то есть каждые 604800 секунд, это аргумент, переданный в rotatelogs.
Если вы не можете остановить и перезапустить приложение, и оно не может войти через канал, то я думаю, у вас настоящая проблема. Возможно, у других появятся предложения.
Было бы здорово, если бы вы могли отправить весь логротат.
Зачем пытаться использовать kill -HUP? (Классическая перезарядка не перезапускается) метод.
Также ... уточняйте у lsof кто обращается к файлу.
Просто используйте ">>", что означает "добавить", а не ">", что означает создание из ваших сценариев, которые пишут в этот файл. У меня была такая же проблема, и я исправил ее с помощью добавления в свой сценарий.
SomeScript.sh >> output.txt
Надеюсь, что это яснее.