在 CentOS 6.6 上编程时,我删除了一个在屏幕 session 中运行的可执行文件(糟糕,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
有一个可选参数“executable”,它看起来很有前途(好像我可以指定一个不是 /proc/15659/exe
的二进制文件来使用),但这没有用对我来说是Linux's gcore
没有任何这样的论点。
有什么解决方法吗?或者我是否只需要重新启动进程(使用重新创建的可执行文件)并等待我正在跟踪的错误重现?
最佳答案
尽管 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 附加到进程感到焦虑,因为时机非常重要:在准确的正确时间生成核心文件以捕获该错误。
但是nos steered me back onto this path而且,我的担心显然是多余的,GDB 能够为我生成一个可爱的 core.15659
。
关于linux - 在 Linux 下,是否可以 gcore 一个可执行文件已被删除的进程?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/29021096/