☰

重新制作 catalina.out，无需重启服务器

tag-icon • tag-icon tomcat unix
重新制作 catalina.out，无需重启服务器

是否可以在不重启服务器的情况下在 tomcat 服务器上重新创建已删除的 catalina.out？catalina.out 被意外删除，但由于集群配置有问题（4 台服务器，它们似乎相互提取写入 catalina.out 中的数据），因此需要它，但我们现在无法重启服务器（我们需要重启所有 4 台服务器）。如果我们再次创建文件并授予 tomcat 用户所有访问权限，这样就足够了吗？

答案1

不，这还不够。这里的主要问题是您删除的文件仍然存在，或者更准确地说，文件占用的数据区域仍然存在。您无法访问它，因为您已经删除了指向该文件的 inode，但 tomcat 进程仍然有一个指向该文件的文件描述符。从 Tomcat 的角度来看，该文件仍然存在，并且可以写入。如果您创建一个新文件，它将是一个不同的文件，而不是 tomcat 进程当前使用的文件。

但是如果您使用的是 Linux，您可能会挽救这种情况（它可能适用于其他 Unix 变体，我不知道）。

目录中列出的每个打开的文件描述符/proc/(process_id)/fd/。您必须找到 Tomcat 进程的 PID，并在/proc/(tomcat_pid)/fd/目录中查找指向的符号链接/.../catalina.out (deleted)。

您可以创建一个指向上述符号链接的符号链接，生成的文件系统条目将是已删除的catalina.out文件，因此您将能够从中读取。但是，这种方法存在一些问题：

  1. 这是一种“破解”，而不是解决方案。它可能根本不起作用。

  2. 生成的文件仅对运行 Tomcat 进程的用户（以及 root）可用。

  3. Tomcat 退出后，该文件将会消失，最终您将得到一个无效链接。

可能最好重新启动 Tomcat。

答案2

我遇到过类似的情况，有人这样做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 应用程序可能需要五到十分钟以上的时间才能重新启动……

答案3

只需向 tomcat 发送 SIGUSR1 信号。

来自文档：

如果您使用 jsvc 1.0.4 或更高版本（来自 Apache Commons Daemon 项目）启动 Tomcat，则可以向 jsvc 发送 SIGUSR1 信号，让其重新打开其日志文件 

kill -SIGUSR1 <tomcat pid>

这将释放已删除/移动文件的文件锁并创建一个新的文件。

相关内容