Description of problem: On Fedora 34, ABRT does not catch a simulated segfault. A couple of days back, it seemed to work normally, however I did not test a simulated segfault. Version-Release number of selected component (if applicable): abrt-2.14.5-2 How reproducible: Always Steps to Reproduce: 1. Install the will-crash package. 2. Issue the will-segfault command. 3. Wait if Abrt reports the error. Actual results: Abrt will not report any error, nor show them in the list of errors. Expected results: Abrt should be able to catch the error and list it. Additional info: The sleep trick also does not make ABRT to catch it: 1. sleep 1000 & 2. kill -s SIGSEGV %1 In journalctl, the crash is visible: vseved audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-coredump@4-34429-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' bře 11 15:33:36 vseved systemd-coredump[34430]: [🡕] Process 34428 (will_segfault) of user 1000 dumped core. Stack trace of thread 34428: #0 0x0000555f1671a262 crash.constprop.0 (will_segfault + 0x1262) #1 0x0000555f1671a335 varargs (will_segfault + 0x1335) #2 0x0000555f1671a36e f (will_segfault + 0x136e) #3 0x0000555f1671a39d callback (will_segfault + 0x139d) #4 0x00007f354678213f call_me_back (libwillcrash.so + 0x113f) #5 0x0000555f1671a232 recursive.constprop.0 (will_segfault + 0x1232) #6 0x0000555f1671a0f6 main (will_segfault + 0x10f6) #7 0x00007f35465bcb75 __libc_start_main (libc.so.6 + 0x27b75) #8 0x0000555f1671a15e _start (will_segfault + 0x115e) bře 11 15:33:36 vseved systemd[1]: systemd-coredump: Deactivated successfully. There are also some abrt lines, since the boot, but do not know whether it has anything to do it with the problem: ře 11 08:54:43 vseved abrt-dump-journal-oops[1192]: abrt-dump-journal-oops: Found oopses: 1 bře 11 08:54:43 vseved abrt-dump-journal-oops[1192]: abrt-dump-journal-oops: Creating problem directories bře 11 08:54:44 vseved abrt-dump-journal-oops[1192]: Reported 1 kernel oopses to Abrt bře 11 08:54:44 vseved abrt-server[1297]: Can't find a meaningful backtrace for hashing in '.' bře 11 08:54:44 vseved abrt-server[1297]: Preserving oops '.' because DropNotReportableOopses is 'no' bře 11 08:54:44 vseved abrt-notification[1390]: System encountered a non-fatal error in ??() bře 11 08:55:11 vseved abrt-applet[2462]: Failed to rename ‘/home/lruzicka/.abrt/spool’ to ‘/home/lruzicka/.cache/abrt/spool’: Adresář nebo soubor neexistuje bře 11 15:27:57 vseved polkitd[1194]: Operator of unix-session:2 successfully authenticated as unix-user:lruzicka to gain TEMPORARY authorization for action org.freedesktop.problems.getall for system-bus-name::1.357 [/usr/bin/python3 /usr/bin/gnome-abrt] (owned by unix-user:lruzicka)
Tested also in a VM with freshly installed Fedora 34 Beta RC -> same result.
Proposed as a Blocker for 34-final by Fedora user lruzicka using the blocker tracking app because: I am proposing this as a final blocker for Fedora 34, because this problem violates at least two release criteria: * SElinux and crash notifications -> non working abrt cannot ensure this. * Default application functionality
With setenforce 0, Abrt is able to catch it. I will look into the SELinux messages more later.
> bře 11 08:55:11 vseved abrt-applet[2462]: Failed to rename ‘/home/lruzicka/.abrt/spool’ to ‘/home/lruzicka/.cache/abrt/spool’: Adresář nebo soubor neexistuje This looks fishy.
I just tried this on my F34 laptop, and had no problem. I ran will_segfault and a notification showed up right away. I do not have a ~/.abrt at all. Nor do I have a ~/.cache/abrt/spool ; ~/.cache/abrt exists but contains only the file applet_dirlist .
That error looks like it comes from abrt's `migrate_to_xdg_dirs`. Still, unless I'm missing something, it doesn't look like it's fatal.
Discussed during the 2021-03-15 blocker review meeting: [0] The decision to delay the classification of this as a blocker bug was made as this isn't a completely clear call for Final blocker, so since it's confirmed fixed in Beta anyway we're just going to duck it by waiting for that fix to be pushed stable. [0] https://meetbot.fedoraproject.org/fedora-blocker-review/2021-03-15/f34-blocker-review.2021-03-15-16.00.txt
(In reply to Geoffrey Marr from comment #7) > Discussed during the 2021-03-15 blocker review meeting: [0] > > The decision to delay the classification of this as a blocker bug was made > as this isn't a completely clear call for Final blocker, so since it's > confirmed fixed in Beta anyway we're just going to duck it by waiting for > that fix to be pushed stable. > > [0] > https://meetbot.fedoraproject.org/fedora-blocker-review/2021-03-15/f34- > blocker-review.2021-03-15-16.00.txt Discussed during the 2021-03-15 blocker review meeting: [0] The decision to delay the classification of this as a blocker bug was made as this looks like a potential blocker, but we'd like to gather more data and have other testers confirm before deciding. [0] https://meetbot.fedoraproject.org/fedora-blocker-review/2021-03-15/f34-blocker-review.2021-03-15-16.00.txt
I'm not able to reproduce on F34 KDE Beta with all updates applied.
I have the same error on Fedora 33. "systemctl --failed" always shows at least abrt-xorg.service digging into the journal using "journalctl -xe | grep abrt", I get the following error: Mar 23 12:08:24 localhost.localdomain abrt-applet[2617]: Failed to rename ‘/home/ramizouari/.abrt/spool’ to ‘/home/ramizouari/.cache/abrt/spool’: No such file or directory
ABRT works for me on fully updated F34 machine. > Mar 23 12:08:24 localhost.localdomain abrt-applet[2617]: Failed to rename ‘/home/ramizouari/.abrt/spool’ to ‘/home/ramizouari/.cache/abrt/spool’: No such file or directory Is this clean installation, or upgrade from F33? In my case, it was a clean installation. It is possible that there is some upgrade bug.
Did you figure anything out yet, Lukas?
Discussed during the 2021-03-29 blocker review meeting: [0] The decision to classify this bug as a "RejectedBlocker (Final)" was made as this appears to be a corner case affecting upgrades only, most testers cannot reproduce it, so impact does not seem broad enough to qualify as a blocker. [0] https://meetbot.fedoraproject.org/fedora-blocker-review/2021-03-29/f34-blocker-review.2021-03-29-16.00.txt
Hi Lukas. Do you remember if this was a clean installation or an upgrade from older release?
Hi Michal, mine was definitely an upgrade from F33.
Thanks for the confirmation. This looks like it could be related to https://bugzilla.redhat.com/show_bug.cgi?id=1881984
This message is a reminder that Fedora Linux 34 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 34 on 2022-06-07. 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 'version' of '34'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 34 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 Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Fedora Linux 34 entered end-of-life (EOL) status on 2022-06-07. Fedora Linux 34 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. Thank you for reporting this bug and we are sorry it could not be fixed.