Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Abrt does not show crashes, although coredumpctl does. #357

Open
lruzicka opened this issue Oct 11, 2024 · 7 comments
Open

Abrt does not show crashes, although coredumpctl does. #357

lruzicka opened this issue Oct 11, 2024 · 7 comments

Comments

@lruzicka
Copy link

I have been trying to test the functionality of Abrt on Fedora 41 and I ran a simple crashing script to case a SEGFAULT. This crash was correctly caught by coredumpctl and could be listed trough it, but there is no trace of anything in Abrt.

I found in journalctl logs:

říj 11 12:42:52 vseved systemd-coredump[162797]: [🡕] Process 162795 (crash) of user 1000 dumped core.
                                                   
                                                   Module /home/lruzicka/todelete/crash without build-id.
                                                   Module /home/lruzicka/todelete/crash
                                                   Stack trace of thread 162795:
                                                   #0  0x0000000000401116 n/a (/home/lruzicka/todelete/crash + 0x1116)
                                                   #1  0x00007fd3d160c248 __libc_start_call_main (libc.so.6 + 0x3248)
                                                   #2  0x00007fd3d160c30b __libc_start_main@@GLIBC_2.34 (libc.so.6 + 0x330b)
                                                   #3  0x0000000000401045 n/a (/home/lruzicka/todelete/crash + 0x1045)
                                                   ELF object binary architecture: AMD x86-64
říj 11 12:42:52 vseved systemd[1]: [email protected]: Deactivated successfully.
říj 11 12:42:52 vseved audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-coredump@1-162796-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
říj 11 12:42:52 vseved audit: BPF prog-id=114 op=UNLOAD
říj 11 12:42:52 vseved audit: BPF prog-id=113 op=UNLOAD
říj 11 12:42:52 vseved audit: BPF prog-id=112 op=UNLOAD
říj 11 12:42:53 vseved abrt-dump-journal-core[1307]: Nepodařilo se získat všechny požadované informace ze žurnálu
říj 11 12:42:53 vseved audit[1307]: AVC avc:  denied  { connectto } for  pid=1307 comm="abrt-dump-journ" path="/run/systemd/userdb/io.systemd.Home" scontext=system_u:system_r:abrt_dump_oops_t:s0 tcontext=system_u:system_r:systemd_homed_t:s0 tclass=unix_stream_socket permissive=0
říj 11 12:42:53 vseved audit[1307]: AVC avc:  denied  { connectto } for  pid=1307 comm="abrt-dump-journ" path="/run/systemd/userdb/io.systemd.Home" scontext=system_u:system_r:abrt_dump_oops_t:s0 tcontext=system_u:system_r:systemd_homed_t:s0 tclass=unix_stream_socket permissive=0
říj 11 12:42:53 vseved audit[94446]: AVC avc:  denied  { watch } for  pid=94446 comm="gmain" path="/etc/mdevctl.d" dev="sdc3" ino=377 scontext=system_u:system_r:virtnodedevd_t:s0 tcontext=system_u:object_r:etc_t:s0 tclass=dir permissive=0
říj 11 12:42:53 vseved abrt-server[162807]: Executable '/home/lruzicka/todelete/crash' doesn't belong to any package and ProcessUnpackaged is set to 'no'
říj 11 12:42:53 vseved abrt-server[162807]: 'post-create' on '/var/spool/abrt/ccpp-2024-10-11-12:42:53.132933-162795' exited with 1
říj 11 12:42:53 vseved abrt-server[162807]: Deleting problem directory '/var/spool/abrt/ccpp-2024-10-11-12:42:53.132933-162795'

It seems like Abrt filters the crashing information and if the crash is not part of any package it is not shown. This, however, hinders testability of Abrt because I cannot rely on crashes happening ad hoc to see whether it works or not.
What alternatives are there for me to induce controlled crashes that would be caught by Abrt and I could test report them to an issue tracker?

Abrt Version: 1.4.3

@lruzicka
Copy link
Author

I also compiled will-crash, because it disappeared from the Fedora repositories, but even with crashes produced via that are not shown in Abrt.

@msrb
Copy link
Member

msrb commented Oct 11, 2024

What alternatives are there for me to induce controlled crashes that would be caught by Abrt and I could test report them to an issue tracker?

You can force-crash pretty much any packaged application. gnome-abrt included:

$ gnome-abrt &
[1] 54832
$ kill -s 6 %1
[1]+  Aborted                 (core dumped) gnome-abrt

@lruzicka
Copy link
Author

Ok, when I do it like this, it works and the error is caught by Abrt. So far so good. But why does not respond it to some of the crashes? Thanks for explaining.

@kparal
Copy link

kparal commented Oct 14, 2024

By default, ABRT only processes crashes in packaged apps. It can be configured in options in ABRT GUI. Maybe that was the reason?

@RokeJulianLockhart
Copy link

RokeJulianLockhart commented Nov 30, 2024

ABRT only processes crashes in packaged apps. It can be configured in options in ABRT GUI. Maybe that was the reason?

@kparal, how does one configure it to capture all crashes instead?

@kparal
Copy link

kparal commented Dec 2, 2024

abrt

It looks like it needs to be done separately for most "Report to Fedora" items. Maybe there's a better way through some config file.

@RokeJulianLockhart
Copy link

RokeJulianLockhart commented Dec 2, 2024

#357 (comment)

@kparal, thanks.

Maybe there's a better way through some config file.

A GUI with federated preferences (like wikipedia.org/wiki/Special:GlobalPreferences) would be useful (although it'd probably necessitate something like bresink.com/osx/300268194/Docs-en/pgs/0030-PrefIntro.html under the hood).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants