就我的盒子而言，发生了一些非常令人困惑的事情。
以下是我的设置/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 中运行，现在它运行正常。