Core dump generation on Linux

Question

Something very perplexing is going on, with respect to my box.

Below are my settings in /etc/sysctl.conf:

kernel.core_pattern = core
kernel.core_uses_pid = 1

In /etc/profile, I have this:

ulimit -S -c unlimited >/dev/null 2>1

And I verify everything by looking at :

cat /proc/sys/kernel/core_pattern
cat /proc/sys/kernel/core_uses_pid

So, when we do a ulimit -c, it returns a value of unlimited.

when we do a ulimit -S -c, it returns a value of unlimited.

when we do a ulimit -H -c, it returns a value of unlimited.

And when I run kill -6 against a running process, I don't get a core.

When I run ulimit -c unlimited, and start the process again, and run kill -6, it generates a core.

Can someone explain what the difference between soft limit and hard limit is?

And should we be changing the hard limit at all?

I don't like this situation, because the cores are sometimes generated, and sometimes not.

Even if I change limits.conf, I really would like an understanding of what I am doing.

A few more things I need to disclose is that I am running on a RHEL 6 environment (x86_64).

And that there is enough disk space, and it is not a DAEMON process, or a setuid program. And there is sufficient permissions in the folder to create new files, and there are no files/folders called core in the runtime directory.

Answer 1

So, the whole reason this was happening was because the script was being run in sh prompt, as against bash prompt, where the ulimit was set. Isn't that weird? We changed the script to run in bash, and it works fine now.

Answer 2

You can read about hard vs. soft limits in the Bash manual section on ulimit.

Since you say you get a core file if you restart the program from your shell, the problem is likely that the original process is not getting started in an environment that reads /etc/profile (that file is only read for login shells). You might consider adding ulimit -c unlimited to whatever script is starting that program (before the line that starts it, of course).