![Linux 上的核心转储生成](https://linux22.com/image/1396440/Linux%20%E4%B8%8A%E7%9A%84%E6%A0%B8%E5%BF%83%E8%BD%AC%E5%82%A8%E7%94%9F%E6%88%90.png)
就我的盒子而言,发生了一些非常令人困惑的事情。
以下是我的设置/etc/sysctl.conf
:
kernel.core_pattern = core
kernel.core_uses_pid = 1
在 中/etc/profile
,我有这个:
ulimit -S -c unlimited >/dev/null 2>1
我通过以下方式验证了一切:
cat /proc/sys/kernel/core_pattern
cat /proc/sys/kernel/core_uses_pid
因此,当我们执行 时ulimit -c
,它会返回 的值unlimited
。
当我们执行 a 时ulimit -S -c
,它返回一个值unlimited
。
当我们执行 a 时ulimit -H -c
,它返回一个值unlimited
。
当我运行kill -6
一个正在运行的进程时,我没有得到核心。
当我运行ulimit -c unlimited
,并再次启动该过程,并运行kill -6
,它会生成一个核心。
有人能解释一下软限制和硬限制之间的区别吗?
我们是否应该改变这个硬限制?
我不喜欢这种情况,因为核心有时会生成,有时则不会。
即使我改变了 limits.conf,我确实希望了解我在做什么。
我需要披露的其他一些事情是,我在 RHEL 6 环境(x86_64)中运行。
并且有足够的磁盘空间,并且它不是 DAEMON 进程或 setuid 程序。并且文件夹中有足够的权限来创建新文件,并且运行时目录中没有名为 core 的文件/文件夹。
答案1
您可以在 Bash 手册部分中阅读有关硬限制与软限制的内容限制。
由于您说从 shell 重新启动程序时会得到一个核心文件,因此问题可能是原始进程未在读取的环境中启动/etc/profile
(该文件仅供登录 shell 读取)。您可以考虑添加到ulimit -c unlimited
启动该程序的任何脚本中(当然是在启动它的行之前)。
答案2
因此,发生这种情况的全部原因是脚本是在 sh 提示符下运行的,而不是在 bash 提示符下运行的,ulimit 是在 bash 提示符下设置的。这不是很奇怪吗?我们将脚本改为在 bash 中运行,现在它运行正常。