在Linux下，是否有可能对可执行文件已被删除的进程进行gcore？

Question

在CentOS 6.6上编程时，我删除了一个在屏幕会话中运行的可执行文件(whoops，make clean)。

现在，不相关，我想gcore这个进程来调试一些东西。我已经重建了可执行文件，但是gcore不接受替换的文件。它知道原始文件被删除了，不让我转储核心文件。

# gcore 15659
core.YGsoec:4: Error in sourced command file:
/home/dev/bin/daemon/destinyd (deleted): No such file or directory.
gcore: failed to create core.15659

# ls -l /proc/15659/exe
lrwxrwxrwx. 1 root root 0 Mar 12 21:33 /proc/15659/exe -> /home/dev/bin/daemon/destinyd (deleted)

# ln -s /proc/15659/exe /home/dev/bin/daemon/destinyd
ln: creating symbolic link `/home/dev/bin/daemon/destinyd': File exists

# rm /proc/15659/exe
rm: remove symbolic link `/proc/15659/exe'? y
rm: cannot remove `/proc/15659/exe': Permission denied

gcore有一个可选的参数“可执行文件”，它看起来很有希望(好像我可以指定一个不是/proc/15659/exe的二进制文件)，但是这对我来说没有用，因为gcore没有任何这样的参数。

有什么解决办法吗？或者，我是否只需要重新启动进程(使用重新创建的可执行文件)，然后等待正在跟踪的bug自我复制？

Answer 1

尽管有ls -l /proc/15659/exe的输出，但实际上通过该路径仍然可以使用原始的可执行文件。

因此，我不仅能够使用简单的cp恢复原始文件(尽管这不足以恢复链接并使gcore工作)，而且我还能够将GDB作为可执行的路径附加到进程中：

# gdb -p 15659 /proc/15659/exe

然后运行"generate-core-file“命令，然后是"detach”。

然后，我可以根据需要检查核心文件：

# gdb /proc/15659/exe core.15659

事实上，我已经忘记了GDB生成核心文件的能力，而且我还担心会将GDB实际附加到进程中，因为时间非常重要:在正确的时间生成核心文件以捕获该错误。

但是 steered me back onto this path和我的担心显然是没有根据的，GDB能够为我生产出一个可爱的core.15659。