Можно ли переделать удаленный catalina.out на сервере tomcat без перезапуска сервера? Catalina.out был случайно удален, но он нужен из-за нестандартной конфигурации кластера (4 сервера, и они, кажется, черпают данные друг от друга, которые записаны в catalina.out), но мы не можем перезапустить сервер (нам понадобится перезапустить все 4) прямо сейчас. Будет ли достаточно, если мы просто создадим файл снова и предоставим пользователю tomcat полный доступ к нему?
Нет, этого было бы недостаточно. Основная проблема здесь в том, что удаленный файл все еще существует, или, если быть точным, все еще существует область данных, которую он занимает. Вы не можете получить к нему доступ, так как вы удалили индексный дескриптор, указывающий на файл, но процесс tomcat все еще имеет файловый дескриптор, указывающий на этот файл. С точки зрения Tomcat, файл все еще существует, и в него можно записать. Если вы создадите новый файл, это будет другой файл, а не тот, который в настоящее время используется процессом tomcat.
Однако, если вы используете Linux, вы можете спасти ситуацию (это может сработать для других вариантов Unix, я не знаю).
Каждый дескриптор открытого файла, указанный в /proc/(process_id)/fd/ каталоги. Вам нужно найти PID процесса Tomcat и посмотреть в /proc/(tomcat_pid)/fd/ каталог для символической ссылки, указывающей на /.../catalina.out (deleted).
Вы можете создать символическую ссылку, указывающую на указанную выше символическую ссылку, и результирующая запись файловой системы будет удалена catalina.out файл, поэтому вы сможете читать из него. Однако у этого подхода есть несколько проблем:
Это «взлом», а не решение. Это может вообще не сработать.
Полученный файл будет доступен только пользователю, который запускает процесс Tomcat (и для root).
После выхода Tomcat файл исчезнет, и вы получите неработающую ссылку.
Наверное, лучше просто перезапустить Tomcat.
Просто отправьте сигнал SIGUSR1 коту.
Из документация:
Если вы используете jsvc 1.0.4 или новее (из проекта Apache Commons Daemon) для запуска Tomcat, вы можете отправить сигнал SIGUSR1 в jsvc, чтобы он повторно открыл свои файлы журнала.
kill -SIGUSR1 <tomcat pid>
Это снимет блокировку удаленного / перемещенного файла и создаст новый.
У меня была похожая ситуация, когда кто-то сделал rm -rf catalina.out вместо усечения файла, в результате чего файловые дескрипторы работали следующим образом:
$ ls -asl /proc/$PID/fd | grep catalin
Nov 29 11:56 1 -> /opt/tomcat/logs/catalina.out (deleted)
Nov 29 11:56 2 -> /opt/tomcat/logs/catalina.out (deleted)
Чтобы исправить это, вы можете использовать инструмент «gdb». Вам нужно будет найти pid вашего процесса, например, например:
ps faux | grep java
Затем используйте инструмент «gdb», чтобы присоединить процесс и изменить дескрипторы файлов. Но пока процесс прикреплен, услуга будет недоступна.
gdb attach $PID
(gdb) p close(1)
$1 = 0
(gdb) p close(2)
$2 = 0
(gdb) p fopen("/opt/tomcat/logs/catalina-gdb.out", "w")
$3 = 11226208
(gdb) p fileno($3)
$4 = 1
(gdb) quit
A debugging session is active.
Inferior 1 [process 9845] will be detached.
Quit anyway? (y or n) y
I did touch the file and set the correct ownership before doing this, but it should not be necessary.
Я нашел это исправление здесь:
http://dnaeon.github.io/remove-file-handles-with-gdb/
В некоторых случаях это предпочтительнее перезапуска tomcat, потому что для перезапуска некоторых java-приложений может потребоваться более пяти или десяти минут ...