= System Wide Change: Enable coredumpctl by default = https://fedoraproject.org/wiki/Changes/coredumpctl
Change owner(s): * Michael Catanzaro <mcatanzaro AT gnome DOT org>
Enable coredumpctl by default. Core dumps will be stored in the system journal rather than created in the crashing process's current working directory by ABRT.
== Detailed Description == coredumpctl will be enabled by default. Core dumps will now be stored in the systemd journal, rather than created in the crashing process's current working directory by ABRT. Currently abrt-ccpp.service installs its own core pattern to /proc/sys/kernel/core_pattern that overrides the core pattern set by systemd. We will simply disable abrt-ccpp.service in the Fedora systemd presets to avoid this. This is of course only a change in default behavior. It will still be possible and easy to revert to the previous Fedora behavior by enabling and starting abrt-ccpp.service, or to traditional Linux behavior by overriding the sysctl variable kernel.core_pattern.
Note that coredumpctl is intended as a developer tool, not as an automatic bug reporting tool nor as a replacement for ABRT. ABRT will continue to automatically report C and C++ crashes to the Fedora Analysis Framework (FAF), and users will still be able to manually report crashes to Red Hat Bugzilla using ABRT's Problem Reporting application. Nor does coredumpctl replace ABRT's ability to catch non-C/C++ issues like Java exceptions, Python exceptions, or machine check events. ABRT remains an important component of Fedora, and will continue to function largely as before as it has support for retrieving core files from the system journal using abrt-vmcore.service. However, it must be admitted that ABRT's feature set will be slightly smaller with abrt-ccpp.service disabled. Notably, crash-time stacktraces will no longer be available as all stacktraces will be generated from core files extracted from the system journal. This could result in reduced-quality for the truncated stacktraces that are used in FAF and the first comment in Bugzilla, but it will not affect the detailed stacktraces that are uploaded as Bugzilla attachments.
== Scope == * Proposal owners: We will disable abrt-ccpp.service in our systemd presets. That's it.
* Other developers: We request some assistance from SELinux developers to address an incompatibility between SELinux and coredumpctl that was introduced in Fedora 24, RHBZ #1341829.
* Release engineering: No changes needed
* List of deliverables: No changes needed
* Policies and guidelines: No changes needed
* Trademark approval: Not needed for this change
On 2016-12-05 18:54, Jan Kurik wrote:
= System Wide Change: Enable coredumpctl by default = https://fedoraproject.org/wiki/Changes/coredumpctl
Change owner(s):
- Michael Catanzaro <mcatanzaro AT gnome DOT org>
Enable coredumpctl by default. Core dumps will be stored in the system journal rather than created in the crashing process's current working directory by ABRT.
The description here is a bit confusing, and scary: what if I run out of space and I need to rm the coredumps to make room? If the coredumps are stored in the same file as the systemd journal I'd loose my system logs too, so it makes no sense to have them in the same file.
Even though [1] says "By default, systemd-coredump will log the core dump including a backtrace if possible to the journal and store the core dump itself in an external file in /var/lib/systemd/coredump." This sounds good, I can rm the coredump and not loose the system log (or the fact that a coredump occured).
But [1] also says "Core dumps can be written to the journal or saved as a file". This is confusing, because you say the only change is to disable an ABRT service:
== Scope ==
- Proposal owners:
We will disable abrt-ccpp.service in our systemd presets. That's it.
But by default systemd would store core dumps in a file, and not in the system journal, so am I correct that this change entry's description should be changed to:
"Enable coredumpctl by default. Core dumps will be logged in the system journal and stored in /var/lib/systemd/coredump rather than created in the crashing process's current working directory by ABRT."
[1] https://www.freedesktop.org/software/systemd/man/systemd-coredump.html
== Detailed Description == coredumpctl will be enabled by default. Core dumps will now be stored in the systemd journal,
same change here "logged in the system journal and stored in /var/lib/systemd/coredump"
rather than created in the crashing process's current working directory by ABRT. Currently abrt-ccpp.service installs its own core pattern to /proc/sys/kernel/core_pattern that overrides the core pattern set by systemd. We will simply disable abrt-ccpp.service in the Fedora systemd presets to avoid this. This is of course only a change in default behavior. It will still be possible and easy to revert to the previous Fedora behavior by enabling and starting abrt-ccpp.service, or to traditional Linux behavior by overriding the sysctl variable kernel.core_pattern.
Note that coredumpctl is intended as a developer tool, not as an automatic bug reporting tool nor as a replacement for ABRT. ABRT will continue to automatically report C and C++ crashes to the Fedora Analysis Framework (FAF), and users will still be able to manually report crashes to Red Hat Bugzilla using ABRT's Problem Reporting application. Nor does coredumpctl replace ABRT's ability to catch non-C/C++ issues like Java exceptions, Python exceptions, or machine check events. ABRT remains an important component of Fedora, and will continue to function largely as before as it has support for retrieving core files from the system journal using abrt-vmcore.service.
same change: retrieved from /var/lib/systemd/coredump, not the systemd journal (maybe the filename of the coredump is retrieved from the journal?)
However, it must be admitted that ABRT's feature set will be slightly smaller with abrt-ccpp.service disabled. Notably, crash-time stacktraces will no longer be available as all stacktraces will be generated from core files extracted from the system journal.
same change: retrieved from /var/lib/systemd/coredump
Best regards, --Edwin
On 12/05/2016 12:27 PM, Török Edwin wrote:
The description here is a bit confusing, and scary: what if I run out of space and I need to rm the coredumps to make room? If the coredumps are stored in the same file as the systemd journal I'd loose my system logs too, so it makes no sense to have them in the same file.
This is possibly compounded by the fact that /var/log/journal and /var/lib/systemd/coredump are usually on the root filesystem, which is also used by the updates, which may load up few gigabytes into /var/cache/dnf IIRC, and need significant extra space while updating.
This is mitigated by dnf actually doing free space requirement estimation, and by journalctl managing its log file size. I just had to do it on most recent F25 update: IIRC, I had ~5GB left free on a small root, DNF required 3GB extra, and the log files were about 5GB, so I did 'journalctl --vacuum-size 2G' which was almost instantaneous.
On Mon, 2016-12-05 at 19:27 +0200, Török Edwin wrote:
The description here is a bit confusing, and scary: what if I run out of space and I need to rm the coredumps to make room?
Sorry, that description is wrong; core dumps used to be stored in the journal and still can be, but that's not the default behavior of systemd-coredump anymore. Thanks to Zbigniew for pointing out this mistake on the desktop list. By default, only truncated stack traces and metadata about the core dumps are actually stored in the journal. The core dumps themselves will be stored in /var/lib/systemd/coredump, where they will be removed automatically based on how old they are and how much space they take up. See coredump.conf(5) for more information on these settings and how to change them. I've edited the change page to be more accurate.
Even though [1] says "By default, systemd-coredump will log the core dump including a backtrace if possible to the journal and store the core dump itself in an external file in /var/lib/systemd/coredump." This sounds good, I can rm the coredump and not loose the system log (or the fact that a coredump occured).
Yes, this is correct.
But [1] also says "Core dumps can be written to the journal or saved as a file". This is confusing, because you say the only change is to disable an ABRT service:
Writing core dumps to the journal is a non-default option. By default, they will be saved to a file, not the journal.
Currently abrt-ccpp.service intercepts all core dumps before they ever reach systemd-coredump, so the only change needed to get coredumpctl working is indeed to disable that service.
But by default systemd would store core dumps in a file, and not in the system journal, so am I correct that this change entry's description should be changed to:
"Enable coredumpctl by default. Core dumps will be logged in the system journal and stored in /var/lib/systemd/coredump rather than created in the crashing process's current working directory by ABRT."
Yes you are correct. I've changed the page accordingly.
However, it must be admitted that ABRT's feature set will be slightly smaller with abrt-ccpp.service disabled. Notably, crash-time stacktraces will no longer be available as all stacktraces will be generated from core files extracted from the system journal.
same change: retrieved from /var/lib/systemd/coredump
We're not actually sure if this will really regress, so I've just removed it from the change page.
Thanks for the feedback,
Michael
On Mon, 05.12.16 19:27, Török Edwin (edwin+ml@etorok.eu) wrote:
On 2016-12-05 18:54, Jan Kurik wrote:
= System Wide Change: Enable coredumpctl by default = https://fedoraproject.org/wiki/Changes/coredumpctl
Change owner(s):
- Michael Catanzaro <mcatanzaro AT gnome DOT org>
Enable coredumpctl by default. Core dumps will be stored in the system journal rather than created in the crashing process's current working directory by ABRT.
The description here is a bit confusing, and scary: what if I run out of space and I need to rm the coredumps to make room?
Much the same as for the journal, there's built-in disk space management. By default we'll make sure to leave at least 15% of the disk free.
Lennart
Jan Kurik jkurik@redhat.com writes:
Note that coredumpctl is intended as a developer tool,
As a developer, I remove abrt and anything else that redirects cores away from my development area. It's really hard to debug a core dump if you can't find the core file.
Just sayin'
On Mon, Dec 05, 2016 at 02:36:13PM -0500, DJ Delorie wrote:
Jan Kurik jkurik@redhat.com writes:
Note that coredumpctl is intended as a developer tool,
As a developer, I remove abrt and anything else that redirects cores away from my development area. It's really hard to debug a core dump if you can't find the core file.
You still can restore such behaviour pretty easily. Just set the kernel.core_pattern sysctl.
systemd-coredump+coredumpctl give you pretty easy access to core files, they are just dumped into /var/lib/systemd/coredump/. The advantage is that a) things are logged and can be easily looked up and queried, b) you get a lot of metadata like open files, cgroups, /proc/mountinfo, umask, capability masks, etc., c) a stacktrace is automatically generated and logged locally, d) old coredumps are automatically removed, e) you cannot fill your disk with coredumps.
The last two points are crucial for "casual" users, who might want to have easy access to the occasional crash without expending too much attention.
Zbyszek
" ---------- Původní zpráva ---------- Od: Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl Komu: Development discussions related to Fedora <devel@lists.fedoraproject. org> Datum: 5. 12. 2016 21:57:12 Předmět: Re: F26 System Wide Change: Enable coredumpctl by default
"On Mon, Dec 05, 2016 at 02:36:13PM -0500, DJ Delorie wrote:
Jan Kurik jkurik@redhat.com writes:
Note that coredumpctl is intended as a developer tool,
As a developer, I remove abrt and anything else that redirects cores away from my development area. It's really hard to debug a core dump if you can't find the core file.
You still can restore such behaviour pretty easily. Just set the kernel.core_pattern sysctl. "
Please don't set kernel.core_pattern to "core" or any path unless you set the default RLIMIT_CORE to 0.
Otherwise you will get core dump files littered all around your file system.
The default value of RLIMIT_CORE, that was 0 for decades, has been changed to 'unlimited' in systemd-229.
" systemd-coredump+coredumpctl give you pretty easy access to core files, they are just dumped into /var/lib/systemd/coredump/. The advantage is that a) things are logged and can be easily looked up and queried, b) you get a lot of metadata like open files, cgroups, /proc/mountinfo, umask, capability masks, etc., c) a stacktrace is automatically generated and logged locally, d) old coredumps are automatically removed, e) you cannot fill your disk with coredumps. "
You are describing the ABRT coredumping solution, aren't you? :)
No, seriously, I have to admit that coredumpctl is much more popular
and provides great experience for developers.
We did a big mistake when we were trying to preserve the old school coredumping in CWD.
Regards,
Jakub "
Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl writes:
You still can restore such behaviour pretty easily. Just set the kernel.core_pattern sysctl.
Yup, that's what I do. Just adding my two cents on Fedora trying to help me "be a developer" without doing what I need as a developer.
But I typically uninstall abrt too.
If you remove ABRT and set kernel.core_pattern to 'core', then if you don't configure systemd to use RLIMIT_CORE=0, every crashing process will create
a new core dump file in its CWD:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/ message/HQ4JFTYLPT5GRW6AD4M2MWGMRAPE7ITN/
Jakub
---------- Původní zpráva ---------- Od: DJ Delorie dj@redhat.com Komu: Development discussions related to Fedora <devel@lists.fedoraproject. org> Datum: 5. 12. 2016 23:08:56 Předmět: Re: F26 System Wide Change: Enable coredumpctl by default
" Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl writes:
You still can restore such behaviour pretty easily. Just set the kernel.core_pattern sysctl.
Yup, that's what I do. Just adding my two cents on Fedora trying to help me "be a developer" without doing what I need as a developer.
But I typically uninstall abrt too. _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org "
On 12/05/2016 12:55 PM, Zbigniew Jędrzejewski-Szmek wrote:
systemd-coredump+coredumpctl give you pretty easy access to core files, they are just dumped into /var/lib/systemd/coredump/. The advantage is that a) things are logged and can be easily looked up and queried, b) you get a lot of metadata like open files, cgroups, /proc/mountinfo, umask, capability masks, etc., c) a stacktrace is automatically generated and logged locally, d) old coredumps are automatically removed, e) you cannot fill your disk with coredumps.
The last two points are crucial for "casual" users, who might want to have easy access to the occasional crash without expending too much attention.
Zbyszek
The last two points are solved by setting the soft ulimit to 0, meanwhile systemd-coredump steals away my core dumps and requires privileged operations to retrieve them.
On 12/05/2016 05:46 PM, Nicholas Miell wrote:
On 12/05/2016 12:55 PM, Zbigniew Jędrzejewski-Szmek wrote:
systemd-coredump+coredumpctl give you pretty easy access to core files, they are just dumped into /var/lib/systemd/coredump/. The advantage is that a) things are logged and can be easily looked up and queried, b) you get a lot of metadata like open files, cgroups, /proc/mountinfo, umask, capability masks, etc., c) a stacktrace is automatically generated and logged locally, d) old coredumps are automatically removed, e) you cannot fill your disk with coredumps.
The last two points are crucial for "casual" users, who might want to have easy access to the occasional crash without expending too much attention.
Zbyszek
The last two points are solved by setting the soft ulimit to 0, meanwhile systemd-coredump steals away my core dumps and requires privileged operations to retrieve them.
Also the automatically generated stack traces are wrong.
On Mon, Dec 05, 2016 at 05:58:19PM -0800, Nicholas Miell wrote:
On 12/05/2016 05:46 PM, Nicholas Miell wrote:
On 12/05/2016 12:55 PM, Zbigniew Jędrzejewski-Szmek wrote:
systemd-coredump+coredumpctl give you pretty easy access to core files, they are just dumped into /var/lib/systemd/coredump/. The advantage is that a) things are logged and can be easily looked up and queried, b) you get a lot of metadata like open files, cgroups, /proc/mountinfo, umask, capability masks, etc., c) a stacktrace is automatically generated and logged locally, d) old coredumps are automatically removed, e) you cannot fill your disk with coredumps.
The last two points are crucial for "casual" users, who might want to have easy access to the occasional crash without expending too much attention.
Zbyszek
The last two points are solved by setting the soft ulimit to 0,
No, they are not. Of course if you set the ulimit to 0, you don't get coredumps, so they don't accumulate. But if you *do* want coredumps, you have to set it to non-zero, and then you're back to square one: if things keep crashing, the kernel will litter your filesystem with coredumps as long as there is space.
meanwhile systemd-coredump steals away my core dumps and requires privileged operations to retrieve them.
No, it doesn't. Coredumps are accessible to the user that the program was running under. So you can see your coredumps, and privileges are only required to see coredumps of system programs. And anything else would be a gigantic hole, so I don't think there's an alternative to this.
Also the automatically generated stack traces are wrong.
I'd appreciate a bug report on that. Otherwise, it's just trolling.
Zbyszek
On 12/05/2016 07:05 PM, Zbigniew Jędrzejewski-Szmek wrote:
meanwhile systemd-coredump steals away my core dumps and requires privileged operations to retrieve them.
No, it doesn't. Coredumps are accessible to the user that the program was running under. So you can see your coredumps, and privileges are only required to see coredumps of system programs. And anything else would be a gigantic hole, so I don't think there's an alternative to this.
Yes, it does. I tested it again right before writing that mail.
[root@entropy ~]# coredumpctl | tail -n 4 Mon 2016-12-05 17:40:52 PST 17229 500 500 11 /home/nicholas/src/bitbucket/crash Mon 2016-12-05 17:41:40 PST 17278 500 500 11 * /home/nicholas/src/bitbucket/crash Mon 2016-12-05 17:47:05 PST 17375 500 500 11 * /home/nicholas/src/bitbucket/crash Mon 2016-12-05 17:51:00 PST 17586 500 500 11 * /home/nicholas/src/bitbucket/crash
[nicholas@entropy ~]$ coredumpctl No coredumps found.
Also the automatically generated stack traces are wrong.
I'd appreciate a bug report on that. Otherwise, it's just trolling.
---------- Původní zpráva ---------- Od: DJ Delorie dj@redhat.com Komu: Development discussions related to Fedora <devel@lists.fedoraproject. org> Datum: 5. 12. 2016 20:37:43 Předmět: Re: F26 System Wide Change: Enable coredumpctl by default
" Jan Kurik jkurik@redhat.com writes:
Note that coredumpctl is intended as a developer tool,
As a developer, I remove abrt and anything else that redirects cores away from my development area. It's really hard to debug a core dump if you can't find the core file." ""---------- Původní zpráva ----------""Od: DJ Delorie dj@redhat.com"" Komu: Development discussions related to Fedora <devel@lists.fedoraproject. org>""Datum: 5. 12. 2016 20:37:43""Předmět: Re: F26 System Wide Change: Enable coredumpctl by default"" "" ""Jan Kurik jkurik@redhat.com writes:""> Note that coredumpctl is intended as a developer tool,"" ""As a developer, I remove abrt and anything else that redirects cores""away from my development area. It's really hard to debug a core dump if""you can' t find the core file."" ""Just sayin'""_______________________________________________""devel mailing list -- devel@lists.fedoraproject.org""To unsubscribe send an email to devel-leave@lists.fedoraproject.org" Just sayin' " "
Then you have no problem with this change, because if you remove
ABRT, systemd-coredump takes over core dumping :)
Regards,
Jakub "
Dne 5.12.2016 v 17:54 Jan Kurik napsal(a):
Note that coredumpctl is intended as a developer tool, not as an automatic bug reporting tool nor as a replacement for ABRT.
Who is main user of Fedora? Developer (who may prefer coredumpctl) or normal user (who may prefer bug reporting tool)?
ABRT already handles these cases well as a bug reporting tool for system packages, and it is already able to handle crashes of unpackaged applications with some configuration changes, but it is not as convenient to use for development purposes as coredumpctl. For instance, simply running 'coredumpctl gdb' will automatically launch gdb and generate a stacktrace for the most recent crash that occured on the system.
If you want to get stack trace with abrt you can simply
# less /var/spool/abrt/*/backtrace
As ABRT already generates it for you (if you have debuginfo installed). If you do not have debuginfo, you can:
# cd /var/spool/abrt/SOME_CRASH # abrt-action-analyze-ccpp-local
which will download necessary debuginfo, search for already reported duplicates and generate backtrace.
So can you elaborate on "ABRT is not as convenient to use for development purposes as coredumpctl" and give me more examples?
I have counter-proposal.
We have two technologies: ABRT and coredumpctl. Each of them have different purpose and none of them 100 % fit everybody. So instead of discussing which one should be installed by default, we can sit together (ABRT and systemd teams) and integrate it together? So users can get benefits of both services.
Hi,
We have two technologies: ABRT and coredumpctl. Each of them have different purpose and none of them 100 % fit everybody. So instead of discussing which one should be installed by default, we can sit together (ABRT and systemd teams) and integrate it together? So users can get benefits of both services.
Hmm, isn't this as easy as abrt being able to find and analyze coredumps written by coredumpctl (in addition to the coredumps written by the abrt dumper)?
cheers, Gerd
Dne 6.12.2016 v 09:52 Gerd Hoffmann napsal(a):
Hmm, isn't this as easy as abrt being able to find and analyze coredumps written by coredumpctl (in addition to the coredumps written by the abrt dumper)?
Yes, it is quite easy. But ABRT cannot do this query every second/minute/hour. So systemd should have mechanism which notify ABRT that there is new dump (by push event).
To my knowledge, no one from systemd team contacted ABRT team with this.
On Tue, 06.12.16 10:16, Miroslav Suchý (msuchy@redhat.com) wrote:
Dne 6.12.2016 v 09:52 Gerd Hoffmann napsal(a):
Hmm, isn't this as easy as abrt being able to find and analyze coredumps written by coredumpctl (in addition to the coredumps written by the abrt dumper)?
Yes, it is quite easy. But ABRT cannot do this query every second/minute/hour. So systemd should have mechanism which notify ABRT that there is new dump (by push event).
abrt can watch the journal relatively easily. In essence, abrt should store away a "cursor" (which is a short string that identifies a location in the journal), that indicates the location it last read from. And then when running continously:
1. Open the journal sd_journal_open() 2. restrict the output that you only see coredumps with sd_journal_add_match() specifying a match of: MESSAGE_ID=fc2e22bc6ee647b6b90729ab34a250b1 2. If abrt previously stored a cursor, use it with sd_journal_seek_cursor() 3. now iterate through the journal: use sd_journal_enumerate_data()/sd_journal_restart_data() to get any data you want for one specific journal entry, and then sd_journal_next() to skip to the next. 4. For each entry you want the raw naked coredump for: use the data included in the COREUMP field if it is there. If not, there's COREDUMP_FILENAME= which contains the coredump filename. 5. If you reached the end of the journal, use sd_journal_wait() to wait for more entries as they arrive.
The man in particular of sd_journal_next() and sd_journal_wait() have longer examples.
There's currently no concept of "service activation by coredump". That's mostly because it's quite hard to do in a race-free fashion. It's not sufficient to simply make systemd-coredump call out to abrt, as that ignores that coredumps can happen during early boot and late shutdown, and there hence should be an asynchronous element: processes that happen early on or in the last boot cycle should be processed during the normal runtime.
Lennart
---------- Původní zpráva ---------- Od: Lennart Poettering mzerqung@0pointer.de Komu: Development discussions related to Fedora <devel@lists.fedoraproject. org> Datum: 6. 12. 2016 11:11:48 Předmět: Re: F26 System Wide Change: Enable coredumpctl by default
"On Tue, 06.12.16 10:16, Miroslav Suchý (msuchy@redhat.com) wrote:
Dne 6.12.2016 v 09:52 Gerd Hoffmann napsal(a):
Hmm, isn't this as easy as abrt being able to find and analyze coredumps written by coredumpctl (in addition to the coredumps written by the abrt dumper)?
Yes, it is quite easy. But ABRT cannot do this query every second/minute/
hour. So systemd should have mechanism which
notify ABRT that there is new dump (by push event).
abrt can watch the journal relatively easily. In essence, abrt should store away a "cursor" (which is a short string that identifies a location in the journal), that indicates the location it last read from. And then when running continously:
1. Open the journal sd_journal_open() 2. restrict the output that you only see coredumps with sd_journal_add_match() specifying a match of: MESSAGE_ID=fc2e22bc6ee647b6b 90729ab34a250b1 2. If abrt previously stored a cursor, use it with sd_journal_seek_cursor() 3. now iterate through the journal: use sd_journal_enumerate_data()/sd_ journal_restart_data() to get any data you want for one specific journal entry, and then sd_journal_next() to skip to the next. 4. For each entry you want the raw naked coredump for: use the data included in the COREUMP field if it is there. If not, there's COREDUMP_FILENAME= which contains the coredump filename. 5. If you reached the end of the journal, use sd_journal_wait() to wait for more entries as they arrive.
The man in particular of sd_journal_next() and sd_journal_wait() have longer examples.
There's currently no concept of "service activation by coredump". That's mostly because it's quite hard to do in a race-free fashion. It's not sufficient to simply make systemd-coredump call out to abrt, as that ignores that coredumps can happen during early boot and late shutdown, and there hence should be an asynchronous element: processes that happen early on or in the last boot cycle should be processed during the normal runtime.
"
Thank you. The service watching journald for coredumps saved by systemd- coredump already exists:
http://abrt.readthedocs.io/en/latest/examples.html#getting-core-files-from- systemd-coredumctl
Jakub
" "
On Tue, 2016-12-06 at 12:28 +0100, jfilak@fedoraproject.org wrote:
Thank you. The service watching journald for coredumps saved by systemd-coredump already exists:
http://abrt.readthedocs.io/en/latest/examples.html#getting-core-files -from-systemd-coredumctl
This.
The change page does mention that we're not disabling ABRT entirely, as ABRT already has the needed integration to get core dumps from systemd, thanks to Jakub and the other ABRT developers. We're only disabling the component of ABRT that prevents systemd from seeing core dumps. I'm not sure what additional integration would be desired here.
Michael
Dne 6.12.2016 v 15:55 Michael Catanzaro napsal(a):
The change page does mention that we're not disabling ABRT entirely, as ABRT already has the needed integration to get core dumps from systemd, thanks to Jakub and the other ABRT developers. We're only disabling the component of ABRT that prevents systemd from seeing core dumps. I'm not sure what additional integration would be desired here.
This need to be checked: https://bugzilla.redhat.com/show_bug.cgi?id=1341829 it should be fixed now. Should. I did not had time to test it yet.
You should add it to test plan.
On Thu, 2016-12-08 at 14:59 +0100, Miroslav Suchý wrote:
This need to be checked: https://bugzilla.redhat.com/show_bug.cgi?id=1341829 it should be fixed now. Should. I did not had time to test it yet.
You should add it to test plan.
It is part of the test plan already; if core dump generation is broken, you can't possibly see a core dump in coredumpctl.
On 12/05/2016 08:54 AM, Jan Kurik wrote:
= System Wide Change: Enable coredumpctl by default = https://fedoraproject.org/wiki/Changes/coredumpctl
Change owner(s):
- Michael Catanzaro <mcatanzaro AT gnome DOT org>
Enable coredumpctl by default. Core dumps will be stored in the system journal rather than created in the crashing process's current working directory by ABRT.
systemd-coredump (or, rather, journald) ignores the split between system accounts and user accounts as configured in /etc/login.defs ("the authoritative definition of UID/GID space allocation", according to the Fedora wiki) and instead hard codes 1000 as the split*.
The end result is that when systemd-coredump enabled, unprivileged users cannot access their own core dumps. (Or any of their own logs in journald.)
This means that if you are a loyal Fedora user that initially installed before the change from 500 to 1000 (Fedora 15 or earlier) and have been faithfully upgrading from release to release, enabling systemd-coredump by default in Fedora 26 will be a regression in functionality.
systemd-coredump should not be enabled by default in Fedora until this bug is fixed by the systemd developers.
*: It's actually more egregious than that: /etc/login.defs is parsed on the build machine at compile time and the extracted value is hard coded into the various systemd executables which then completely ignore /etc/login.defs at run time.
On Monday, 12 December 2016 at 20:54, Nicholas Miell wrote: [...]
systemd-coredump (or, rather, journald) ignores the split between system accounts and user accounts as configured in /etc/login.defs ("the authoritative definition of UID/GID space allocation", according to the Fedora wiki) and instead hard codes 1000 as the split*.
The end result is that when systemd-coredump enabled, unprivileged users cannot access their own core dumps. (Or any of their own logs in journald.)
This means that if you are a loyal Fedora user that initially installed before the change from 500 to 1000 (Fedora 15 or earlier) and have been faithfully upgrading from release to release, enabling systemd-coredump by default in Fedora 26 will be a regression in functionality.
systemd-coredump should not be enabled by default in Fedora until this bug is fixed by the systemd developers.
*: It's actually more egregious than that: /etc/login.defs is parsed on the build machine at compile time and the extracted value is hard coded into the various systemd executables which then completely ignore /etc/login.defs at run time.
Have you filed a bug (preferably upstream)? If yes, please share the bug number and comment in the FESCo ticket (https://pagure.io/fesco/issue/1654).
Regards, Dominik