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

FreeBSD's gcore有一个可选参数＆＃34; executable ＆＃34;看起来很有希望（好像我可以指定一个二进制文件来使用它不是/proc/15659/exe），但对我来说没有用Linux's gcore没有任何这样的参数。

有任何变通方法吗？或者我只需要重新启动该过程（使用重新创建的可执行文件）并等待我跟踪的错误重现自己？

Answer 1

尽管输出ls -l /proc/15659/exe，但原始可执行文件实际上仍可通过该路径获得。

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

# gdb -p 15659 /proc/15659/exe

然后运行＆＃34; generate-core-file＆＃34;命令，然后是＆＃34; detach＆＃34;。

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

# gdb /proc/15659/exe core.15659

事实上，我已经忘记了GDB生成核心文件的能力，而且我担心实际将GDB附加到流程中，因为时间非常重要：在恰当的时间生成核心文件以捕获该bug。 / p>

但nos steered me back onto this path而且，我的担心显然毫无根据，GDB能够为我制作一个可爱的core.15659。

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

1 个答案: