I am using SLES 12.4 VM where I have a custom daemon dumping core frequently as I see from /var/log/messages and coredumpctl. But I never see a core file in /var/lib/systemd/coredump/ or in any other location. I do see an error in /var/log/messages as:

systemd-coredump[<PID>]: Failed to parse resource limit: <daemon_name>

I have already set core size limit to unlimited in /etc/security/limits.conf. Also I have enabled application core dumping in /etc/systemd/coredump.conf. However, when i manually run:

[ 12.4 sles ~]# kill -SEGV <daemon PID>

I am able to find the core in /var/lib/systemd/coredump.


#<domain>      <type>  <item>         <value>

*                soft    core            -1
#*               hard    rss             10000
#@student        hard    nproc           20
#@faculty        soft    nproc           20
#@faculty        hard    nproc           50
#ftp             hard    nproc           0
#@student        -       maxlogins       4




kernel.core_pattern=|/usr/lib/systemd/systemd-coredump %p %u %g %s %t %e

Ulimit status:

[12.4-sles:~]# ulimit -c

How do I get the core for the kernel initiated core dump?


1 Answer 1


It looks like the contents of your /etc/sysctl.d/50-coredump.conf are incorrect, there should be an additional %c there between the %t and %e fields.

You can see that in the change that introduced support for passing the ulimit -c around to systemd-coredump to decide whether to save or truncate the coredump file (in other words, to respect the ulimit -c setting.)

That change required a change in command line of the kernel.core_pattern sysctl, but it seems in your system the old version of that file is present.

This might be due to RPM thinking it needed to preserve the original file (look for a /etc/sysctl.d/50-coredump.conf.rpmnew or another .rpm* extension might give you a clue.)

In any case, updating that file should solve the problem for you.

For more into root causing this issue, I looked at the message you reported:

systemd-coredump[<PID>]: Failed to parse resource limit: <daemon_name>

I then found that message here in the source tree, but that code is expecting to receive an RLIMIT that can be parsed into a number, so when you mentioned you get that message with the <daemon_name> there, it struck me as the fields you're getting are in the wrong order...

Looking at your 50-coredump.conf and comparing it to the one from the upstream tree quickly led me to the conclusion that the problem you're having is most likely due to that mismatch.

  • The error message is no longer visible. But I see a different message as: Core dumping is disabled for thr process: <daemon_name> and still I don't see a core file...
    – Anirban
    Commented Mar 11, 2019 at 10:01

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .