Hide Forgot
Description of problem: When using systemd-coredump the resulting core is empty. Version-Release number of selected component (if applicable): 229-13 How reproducible: Always Steps to Reproduce: 1. echo '|/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %e' > /proc/sys/kernel/core_pattern 2. sleep 10 & 3. kill -11 $! Actual results: Empty core is created in /var/lib/systemd/coredump and journal complains about errors processing the core. Expected results: A core is created in /var/lib/systemd/coredump. Additional info: I believe this is a side effect of the fix for https://bugzilla.redhat.com/show_bug.cgi?id=1309172. The patch 0045-coredump-ignore-RLIMIT_CORE.patch removes the line: r = safe_atou64(context[CONTEXT_RLIMIT], &rlimit); This was the only place where rlimit was initialized however the rlimit variable is still being used on the next line which was left in coredump.c: max_size = MIN(rlimit, MAX(arg_process_size_max, arg_external_size_max)); Often this will result in max_size being 0 and an empty core file being created.
*** Bug 1372404 has been marked as a duplicate of this bug. ***
I have seen this as well. It appears that all coredump saving is currently broken in F24 right now because of this. This is a severe bug because it seems to make it impossible to report any coredumps properly in ABRT.
Do you have any non-default settings in /etc/systemd/coredump.conf?
Zbigniew, Nate already identified where the bug is: 'rlimit' is used uninitialized in save_external_coredump().
This appears to still be broken in F25. The version number should be changed. On the first attempt to log into the machine after bootup, gnome-settings-daemon seems to be segfaulting, but I just see some empty cores in /var/lib/systemd/coredump so I don't get any ABRT notifications and can't report it.
Robert, That is strange since systemd-231-10.fc25 does not have the patch which caused this issue. If something similar is happening in F25 it is most likely caused by a different issue and should probably have a separate bug.
I am not sure if it is a different issue. It looks like it's not actually gnome-settings-daemon that's segfaulting, it just exits with a "Unable to initialize GTK+" error. There's a gnome-session-failed process that then segfaults: Nov 28 09:52:24 eng1n65.eng.sedsystems.ca kernel: show_signal_msg: 174 callbacks suppressed Nov 28 09:52:24 eng1n65.eng.sedsystems.ca kernel: gnome-session-f[2126]: segfault at 0 ip 00007f8ad7e87579 sp 00007ffc2af2b810 error 4 in libgtk-3.so.0.2200.4[7f8ad7ba9 Nov 28 09:52:24 eng1n65.eng.sedsystems.ca systemd[1]: Created slice system-systemd\x2dcoredump.slice. Nov 28 09:52:24 eng1n65.eng.sedsystems.ca systemd[1]: Started Process Core Dump (PID 2127/UID 0). Nov 28 09:52:24 eng1n65.eng.sedsystems.ca systemd-coredump[2128]: Core Dumping has been disabled for process 2126 (gnome-session-f). Nov 28 09:52:24 eng1n65.eng.sedsystems.ca systemd-coredump[2128]: Process 2126 (gnome-session-f) of user 1000 dumped core. I am not sure why it reports "Core Dumping has been disabled". The contents of /etc/systemd/coredump.conf and /etc/security/limits.conf both match the defaults according to "rpm -V". Might be due to bug 1365435. However, discussion in that bug claims that ABRT reports aren't affected by that problem, but in this case ABRT is not detecting anything at all. It also claims that systemd coredump handling isn't even supposed to be enabled by default, but it seems to be trying on my system, though I've never done anything to turn it on.
I ran the steps in the description on Fedora 25 and the issue for which I opened this bug seems to be resolved. I believe this is still an issue on Fedora 24.
This message is a reminder that Fedora 24 is nearing its end of life. Approximately 2 (two) weeks from now Fedora will stop maintaining and issuing updates for Fedora 24. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '24'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 24 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 24 changed to end-of-life (EOL) status on 2017-08-08. Fedora 24 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.