Невозможно работать с журналом журнала ловушек (loggc) с логротатом

Я столкнулся с странной проблемой при использовании JVM файла журнала мусора с командой logrotate Linux. Когда выполняется ротация, он заполняет NUL (^ @) значениями первой строки файла, указанной как аргумент JVM.

Скажем, это java-вызов (Test.class находится в /home/test/ ):

java -Xloggc:/home/test/test.log -cp/home/test/Test

Конфигурация logrotate для этого файла следующая:

/home/test/test.log {
    вращение 56
    missok
    notifempty
    copytruncate
    nocreate
    nomail
}

У меня также есть запись в журнале crontab каждую минуту для тестирования:

*/1 * * * */usr/sbin/logrotate -f/etc/logrotate.d/gcLog

Я пришел к выводу, что JVM записывает в режиме добавления и сохраняет какое-то смещение, используемое для записи следующей строки в связанном файле, даже если файл обрезается с помощью logrotate (возможно, я ошибаюсь).
< бр /" >

Моя следующая идея состояла в том, чтобы попытаться перенаправить файл stdout в файл test.log. Я использовал этот java-вызов и сохранил ту же конфигурацию для logrotate и cron:

java -verbose: gc -cp/home/test/Test > /home/test/test.log

Еще раз, когда test.log усекается logrotate, новый созданный файл заполняется значениями NUL (^ @) в первой строке.


Не нужно говорить, что я не нашел ничего полезного, используя Google. Я нашел еще один вопрос о родстве stackoverflow, но мне не удалось настроить Java Script Wrapper, поэтому это не сработает.

Кто-нибудь сталкивался с этой проблемой? Любая идея, почему это происходит? Лучше, любое решение или решение? Мне нужно попробовать подключить вызов к приложению к некоторому Script чтению вывода и, возможно, взглянуть на то, как Tomcat регистрирует и вращает stdout в catalina.out(здесь также будет очень признательна помощь)

Ответы

Ответ 1

У нас была та же проблема, что и у нас на Jboss7 и Java6, мы получали NULL в файле GC, и они просто продолжали расти.

Решение состояло в том, чтобы просто записать GC в stdout, а затем добавить stdout в файл:

Простой пример:

java -verbose:gc >> console.log

Очевидно, использование append ( → ) избавляет Java-указателя от позиции в файле. С дополнительным бонусом, не имеющим журналов GC reset для перезапуска сервера, чтобы мы могли иметь некоторую статистику с течением времени.

По крайней мере, у инструмента IBM PMAT нет проблем с анализом sysout с выходом GC.

Самое простое решение иногда лучше:)

Хотя я бы хотел, чтобы Java поддерживала поворот GC-журналов, как я вижу, кто-то обсуждал это раньше: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2011-April/002061.html

Ответ 2

Чтобы объяснить значение null, Java поддерживает внутреннюю ссылку, подсчитывая позицию для отступа, и по мере того, как вы перемещаете файл из-за того, что в журнал записываются нулевые символы.

Я видел, как я искал файлы журнала GC, чтобы вызвать сбою системы, прерывание, вызванное при записи в файл журнала, игнорируется (см. здесь код http://pastebin.com/HWkNv3PM), в результате чего JVM продолжает игнорировать ошибку.

Когда файл снова открывается, я считаю, что счетчик позиции не является reset.

Что касается других идей о том, как свернуть файлы журналов, см. также: Журналы коллекционирования мусора в java

Ответ 3

Простым обходным решением может быть изменение Java-запроса, который я использовал в моем вопросе:

java -Xloggc:/home/test/test.log -cp/home/test/Test

к

java -verbose: gc -cp/home/test/Test | tee -a/home/test/test/log

Конфигурация logrotate и cron может оставаться неизменной (даже если период cron должен быть увеличен).

Смотрите мой комментарий по вопросу о ссылке, в которой более подробно рассказывается о logrotate и обработчиках файлов в Linux. См. Также brainzzy объяснения о поведении Java.

Ответ 4

вместо java -verbose: gc → console.log можно сделать: java -Xloggc: logs/gc.log → console.log, поэтому вывод будет сохранен в файле, а затем также повернут в console.log?