I run my program on a machine for which I do not have root privileges. The core file is supposed to be handled by abrt:

$ sysctl kernel.core_pattern
kernel.core_pattern = |/usr/libexec/abrt-hook-ccpp %s %c %p %u %g %t e %P %I %h

**Now, how can I obtain the core file? It is not located anywhere in my $HOME, or in the folder where I ran my program.** I tried many locations such as /var/spool, /var/cache, /var/tmp, etc. According to the abrt documentation I made a configuration file $HOME/.config/abrt/settings/abrt-applet.conf containing:

AutoreportingEnabled = yes
ProcessUnpackaged = yes
DumpLocation = /path/to/existing/folder

(only the second variable is from the documentation, the other two are from other abrt files that do not seem understood here) **After creating this file, I did get the mention core dumped line when my program crashes, which was not the case previously, but no core file appeared.**

I have install abrt on AlmaLinux 8 and have triggered a crash:

~]$ sleep 100 &
 2823
~]$ kill -s SIGSEGV 2823

I did see a folder momentarily in the

/var/spool/abrt

but it disappeared within a few seconds. Also I can't seem to change the dump location. When I change the dump location by uncommenting and setting the configuration as

= /home/crash/abrt

and restarting

, it fails to start.

I have webmin/virtualmin install on centos7 server. Does anyone know why I'm getting this ABRT problem? Also, how do I prevent this from happening. ABRT has detected 2 problem(s). For more info run: abrt-cli list --since 1659022602 [root@mail ~]# abrt-cli list --since 1659022602 id ca222c42101aa4916ca8650854c207c97e707387 reason: systemd-journald killed by SIGABRT time: Tue 26 Jul 2022 09:11:46 PM CEST cmdline: /usr/lib/systemd/systemd-journald package: systemd-219-78.el7_9.5 uid: 0 (root) count: 3 Directory: /var/spool/abrt/ccpp-2022-07-26-21:11:46-400 id c4bee002dea451ab58154e5313cad41fcf2d08a1 reason: systemd-journald killed by SIGABRT time: Tue 26 Jul 2022 09:58:50 PM CEST cmdline: /usr/lib/systemd/systemd-journald package: systemd-219-78.el7_9.5 uid: 0 (root) count: 3 Directory: /var/spool/abrt/ccpp-2022-07-26-21:58:49-9109

we want to delete all abrt folders from /var/spool/abrt/ before we just run the following , to see how many folders we have find /var/spool/abrt/ -type d /var/spool/abrt/ /var/spool/abrt/ccpp-2019-09-10-08:05:21-1652 now we runs this to clean the abrt folders find /var/spool/abrt/ -type d -exec abrt-cli rm '{}' \; '/var/spool/abrt' is not a problem directory Can't delete '/var/spool/abrt/': (null) rm '/var/spool/abrt/ccpp-2019-09-10-08:05:21-1652' find: ‘/var/spool/abrt/ccpp-2019-09-10-08:05:21-1652’: No such file or directory and simple verification find /var/spool/abrt/ -type d /var/spool/abrt/ note - no folders but as we can see from command find /var/spool/abrt/ -type d -exec abrt-cli rm '{}' \; output we get also '/var/spool/abrt' is not a problem directory find: ‘/var/spool/abrt/ccpp-2019-09-10-08:05:21-1652’: No such file or directory just want to be sure if I have something wrong with - find /var/spool/abrt/ -type d -exec abrt-cli rm '{}' \; ?

I am experiencing issues with the GNOME problem reporting software (gnome-abrt). I open it up because I want to report the errors I get (I get a lot of crashes in software **and** system crashes) but libreport itself crashes and doesn't let me report the issues. At first I thought it was the custom theme I installed that was causing this:

~$ gnome-abrt

(gnome-abrt:12043): Gtk-WARNING **: 17:29:39.302: Theme parsing error: main-dark.css:2470:0: Expected a valid selector

(org.freedesktop.GnomeAbrt:12068): Gtk-WARNING **: 17:29:42.849: Theme parsing error: main-dark.css:2470:0: Expected a valid selector
free(): double free detected in tcache 2

But switching back to the default theme causes the same:

free(): double free detected in tcache 2

Any help is greatly appreciated.

We want to automate the process of removing old directories from /var/spool/abrt/. We have RHEL machines - version 7.x. The known way is to do the following # systemctl stop abrtd # systemctl stop abrt-oops And we can remove all those directories and files with following rm command: # abrt-cli rm /var/spool/abrt/* And then start the services # systemctl start abrtd # systemctl start abrt-oops We want to simplify the deletion process as the following -- it will delete the directories that are older than 10 days from /var/spool/abrt/ find /var/spool/abrt/ -type d -ctime +10 -exec rm -rf {} \; Is it a good alternative to purge the /var/spool/abrt/ directory?

we are try to remove all folders from /var/spool/abrt/ on rhel 7.2 machines and that after we stop the services abrt-ccpp.service and abrtd.service because we not want any more the core under spool but we get find /var/spool/abrt/ -type d -exec abrt-cli rm '{}' \; '/var/spool/abrt' is not a problem directory Can't delete '/var/spool/abrt/': (null) '/var/spool/abrt/ccpp-2019-11-20-12:13:41-64941' is not a problem directory Can't delete '/var/spool/abrt/ccpp-2019-11-20-12:13:41-64941': (null) '/var/spool/abrt/ccpp-2019-11-20-12:16:12-2687' is not a problem directory Can't delete '/var/spool/abrt/ccpp-2019-11-20-12:16:12-2687': (null) '/var/spool/abrt/ccpp-2019-11-20-14:20:09-61612' is not a problem directory Can't delete '/var/spool/abrt/ccpp-2019-11-20-14:20:09-61612': (null) '/var/spool/abrt/ccpp-2019-11-20-15:12:03-55822' is not a problem directory Can't delete '/var/spool/abrt/ccpp-2019-11-20-15:12:03-55822': (null) the folder under spool are drwx------ 2 root root 4096 Dec 16 11:54 ccpp-2019-11-20-18:43:24-8768 drwx------ 2 root root 4096 Dec 16 11:54 ccpp-2019-11-20-12:14:55-1014 drwx------ 2 root root 4096 Dec 16 11:54 ccpp-2019-11-20-12:21:34-8475 drwx------ 2 root root 4096 Dec 16 11:54 ccpp-2019-11-20-12:25:27-12740 drwx------ 2 root root 4096 Dec 16 11:54 ccpp-2019-11-20-12:32:28-19585 drwx------ 2 root root 4096 Dec 16 11:54 ccpp-2019-11-20-16:13:48-52746 any solution for this problem? we also try find /var/spool/abrt/ -mindepth 1 -type d -exec abrt-cli rm '{}' \; '/var/spool/abrt/ccpp-2019-11-20-12:13:41-64941' is not a problem directory Can't delete '/var/spool/abrt/ccpp-2019-11-20-12:13:41-64941': (null) '/var/spool/abrt/ccpp-2019-11-20-12:16:12-2687' is not a problem directory Can't delete '/var/spool/abrt/ccpp-2019-11-20-12:16:12-2687': (null) '/var/spool/abrt/ccpp-2019-11-20-14:20:09-61612' is not a problem directory Can't delete '/var/spool/abrt/ccpp-2019-11-20-14:20:09-61612': (null) '/var/spool/abrt/ccpp-2019-11-20-15:12:03-55822' is not a problem directory Can't delete '/var/spool/abrt/ccpp-2019-11-20-15:12:03-55822': (null) and we can see that we get the folder as find /var/spool/abrt/ -mindepth 1 -type d -print |more /var/spool/abrt/ccpp-2019-11-20-12:13:41-64941 /var/spool/abrt/ccpp-2019-11-20-12:16:12-2687 /var/spool/abrt/ccpp-2019-11-20-14:20:09-61612 /var/spool/abrt/ccpp-2019-11-20-15:12:03-55822 /var/spool/abrt/ccpp-2019-11-20-18:37:25-2253 /var/spool/abrt/ccpp-2019-11-20-12:22:50-9886 /var/spool/abrt/ccpp-2019-11-20-13:01:41-46329 /var/spool/abrt/ccpp-2019-11-20-13:20:12-582 /var/spool/abrt/ccpp-2019-11-20-14:07:40-48870 /var/spool/abrt/ccpp-2019-11-20-15:15:23-59287 /var/spool/abrt/ccpp-2019-11-20-19:35:27-61003 /var/spool/abrt/ccpp-2019-11-20-11:22:29-12490 /var/spool/abrt/ccpp-2019-11-20-14:44:22-26098 /var/spool/abrt/ccpp-2019-11-20-17:57:35-24985

We have the following folders ls -ltr /var/spool/ abrt drwx------. 2 root root 4096 Mar 11 16:53 ccpp-2020-03-11-15:41:35-1574876666 drwx------. 2 root root 4096 Mar 11 16:53 ccpp-2020-03-11-15:47:52-3964344561 drwx------. 2 root root 4096 Mar 11 16:53 ccpp-2020-03-11-16:00:03-7828477646 drwx------. 2 root root 4096 Mar 11 16:53 ccpp-2020-03-11-16:24:33-1454958470 we try to delete the folders with find /var/spool/abrt/ -type d -ctime +10 -exec abrt-cli rm '{}' \; but abrt-cli not delete them my question , can we delete them without abrt-cli as ( after stop the abrt service ) find /var/spool/abrt/ -type d -ctime +10 -exec rm -rf {} \;

My system config: Red Hat 7.7 [Developer's edition]. Stand Alone system. root@thinkred1cartoon:$ cat /etc/redhat-release Red Hat Enterprise Linux Server release 7.7 (Maipo) root@thinkred1cartoon:$ uname -a Linux thinkred1cartoon.biz 3.10.0-1062.9.1.el7.x86_64 #1 SMP Mon Dec 2 08:31:54 EST 2019 x86_64 x86_64 x86_64 GNU/Linux I'm having problem launching subscription-manager (both CLI or GUI). Error - root@thinkred1cartoon:$ subscription-manager Traceback (most recent call last): File "/usr/sbin/subscription-manager", line 5, in from pkg_resources import load_entry_point File "/usr/lib/python2.7/site-packages/pkg_resources.py", line 3011, in parse_requirements(__requires__), Environment() File "/usr/lib/python2.7/site-packages/pkg_resources.py", line 626, in resolve raise DistributionNotFound(req) pkg_resources.DistributionNotFound: six subscription-manager via CLI or GUI failing to launch I followed this Redhat solution - https://access.redhat.com/solutions/3967521 1. Uninstall packages installed via pip3 pip3 pip freeze --local | xargs pip3 uninstall -y 2. Uninstall packages installed via pip scl enable python27 bash pip freeze --local | xargs pip uninstall -y 3. Uninstalled all python packages from 3rd party listed by command below using "yum remove" rpm -qa --queryformat "%{name}-%{version}-%{release}.%{arch}------->%{vendor}\n" | grep -v "Red Hat" | grep -i python 4. yum reinstall insights-client python-requests python-urllib3 5. yum update -y 6. Rebooted system No luck. Network is fine. yum works with existing enabled repos and I can go on internet via web browser. root@thinkred1cartoon:$ strace -T -tt -f -v -s 1024 -o register.out insights-client --register Traceback (most recent call last): File "/usr/bin/insights-client", line 5, in from pkg_resources import load_entry_point File "/usr/lib/python2.7/site-packages/pkg_resources.py", line 3007, in working_set.require(__requires__) File "/usr/lib/python2.7/site-packages/pkg_resources.py", line 728, in require needed = self.resolve(parse_requirements(requirements)) File "/usr/lib/python2.7/site-packages/pkg_resources.py", line 626, in resolve raise DistributionNotFound(req) pkg_resources.DistributionNotFound: six System error message - root@thinkred1cartoon:$ tail -f /var/log/messages Dec 26 15:54:30 thinkred1cartoon python: detected unhandled Python exception in '/usr/sbin/subscription-manager' Dec 26 15:54:30 thinkred1cartoon python: detected unhandled Python exception in '/usr/sbin/sosreport' Dec 26 15:54:35 thinkred1cartoon python: communication with ABRT daemon failed: timed out Dec 26 15:54:35 thinkred1cartoon python: communication with ABRT daemon failed: timed out Dec 26 15:54:35 thinkred1cartoon abrt-server: sosreport run failed with exit code 1, log follows: Dec 26 15:54:35 thinkred1cartoon abrt-server: Traceback (most recent call last): Dec 26 15:54:35 thinkred1cartoon abrt-server: File "/usr/sbin/sosreport", line 14, in Dec 26 15:54:35 thinkred1cartoon abrt-server: from sos.sosreport import main Dec 26 15:54:35 thinkred1cartoon abrt-server: File "/usr/lib/python2.7/site-packages/sos/__init__.py", line 19, in Dec 26 15:54:35 thinkred1cartoon abrt-server: import six Dec 26 15:54:35 thinkred1cartoon abrt-server: ImportError: No module named six Dec 26 15:54:35 thinkred1cartoon abrt-server: 'post-create' on '/var/spool/abrt/Python-2019-12-26-15:54:30-20008' exited with 1 Dec 26 15:54:35 thinkred1cartoon abrt-server: Deleting problem directory '/var/spool/abrt/Python-2019-12-26-15:54:30-20008' Dec 26 15:54:35 thinkred1cartoon python: detected unhandled Python exception in '/usr/sbin/sosreport' Dec 26 15:54:36 thinkred1cartoon abrt-server: Not saving repeating crash in '/usr/sbin/sosreport' Dec 26 15:54:36 thinkred1cartoon abrt-server: sosreport run failed with exit code 1, log follows: Dec 26 15:54:36 thinkred1cartoon abrt-server: Traceback (most recent call last): Dec 26 15:54:36 thinkred1cartoon abrt-server: File "/usr/sbin/sosreport", line 14, in Dec 26 15:54:36 thinkred1cartoon abrt-server: from sos.sosreport import main Dec 26 15:54:36 thinkred1cartoon abrt-server: File "/usr/lib/python2.7/site-packages/sos/__init__.py", line 19, in Dec 26 15:54:36 thinkred1cartoon abrt-server: import six Dec 26 15:54:36 thinkred1cartoon abrt-server: ImportError: No module named six Dec 26 15:54:36 thinkred1cartoon abrt-server: 'post-create' on '/var/spool/abrt/Python-2019-12-26-15:54:30-20024' exited with 1 Dec 26 15:54:36 thinkred1cartoon abrt-server: Deleting problem directory '/var/spool/abrt/Python-2019-12-26-15:54:30-20024' Any suggestions are appreciated.

we try to delete all abrt folders as the following ( on redhat Linux machines ) find /var/spool/abrt/* -type d -exec abrt-cli rm '{}' \; rm '/var/spool/abrt/ccpp-2018-09-03-14:52:11-5653' rm '/var/spool/abrt/ccpp-2019-03-26-12:18:52-31410' rm '/var/spool/abrt/ccpp-2019-04-07-05:50:25-16907' rm '/var/spool/abrt/ccpp-2019-10-29-14:20:46-20059' pwd /var/spool/abrt but we still see the folders and folder content as ls -ltr /var/spool/abrt total 24 -rw------- 1 root root 70 Nov 5 09:43 last-ccpp -rw-------. 1 root root 48 Dec 9 03:25 last-via-server drwx------ 2 root root 4096 Dec 9 18:45 ccpp-2018-09-03-14:52:11-5653 drwx------ 2 root root 4096 Dec 9 18:45 ccpp-2019-03-26-12:18:52-31410 drwx------ 2 root root 4096 Dec 9 18:45 ccpp-2019-04-07-05:50:25-16907 drwx------ 2 root root 4096 Dec 9 18:45 ccpp-2019-10-29-14:20:46-20059 why abrt-cli rm not removed the folders? from abrt.conf grep -v "^#" /etc/abrt/abrt.conf MaxCrashReportsSize = 1000 DeleteUploaded = no AutoreportingEvent = report_uReport AutoreportingEnabled = no PrivateReports = yes

we have 672 linux redhat machines since we have small /var size and sometimes /var/spool take space , then we want to disable the abrtd service what are the risks for disable the abrtd service ? as the following: systemctl stop abrtd systemctl stop abrt-oops and systemctl disable abrtd systemctl disable abrt-oops

How to stop abrtd permanently? It is filling up the log space and I don't need abrtd logs. 1. Is this command sufficient? $ systemctl stop abrtd 2. Will abrtd be back up and running with system re-start?

I posted this question to StackOverflow a little while ago, but just now found this community, and felt like this is at least an equally appropriate site for this question: I've been led to understand that if abrt-ccpp.service is installed on a Linux PC, it supersedes/overwrites (I've read both, not sure which is true) the file /proc/sys/kernel/core_pattern, which otherwise specifies the location and filename pattern of core files. **Question**: When I execute systemctl, why does abrt-ccpp.service report exited under the SUB column? I don't understand the combination of active and exited: is the service "alive"/active/running or not? > systemctl UNIT LOAD ACTIVE SUB abrt-ccpp.service loaded active exited ... **Question**: Where are core files generated? I wrote this program to generate a SIGSEGV: #include int main(int argc, char* argv[], char* envz[]) { int* pInt = NULL; std::cout g++ main.cpp > ./a.out Segmentation fault (core dumped) But I cannot locate where the core file is generated. **What I have tried**: - Looked in the same directory as my main.cpp. Core file is not there. - Looked in /var/tmp/abrt/ because of the following comment in /etc/abrt/abrt.conf. Core file is not there. ... # Specify where you want to store coredumps and all files which are needed for # reporting. (default:/var/tmp/abrt) # # Changing dump location could cause problems with SELinux. See man_abrt_selinux(8). # #DumpLocation = /var/tmp/abrt ... - Looked in /var/spool/abrt/ because of a comment at this link . Core file is not there. - Edited /etc/abrt/abrt.conf and uncommented and set DumpLocation = ~/foo which is an existing directory. Followed this by restarting abrt-hook-ccpp (sudo service abrt-ccpp restart) and rerunning a.out. Core file was not generated in ~/foo/ - Verified that ulimit -c reports unlimited. I am out of ideas of what else to try and where else to look. In case helpful, this is the content of my /proc/sys/kernel/core_pattern: > cat /proc/sys/kernel/core_pattern |/usr/libexec/abrt-hook-ccpp %s %c %p %u %g %t e Can someone help explain how the abrt-hook-ccpp service works and where it generates core files? Thank you.

ABRT is running on a RHEL7 server, so the kernel conf is : # cat /proc/sys/kernel/core_pattern |/usr/libexec/abrt-hook-ccpp %s %c %p %u %g %t e %P %I All core dumps from application systems/installed packages are located in (default behavior) : /var/spool/abrt. Problem is, when a custom application started by a user crashes, a core dump is generated at the location where the user started it and all the time there is not enough space (generally in user home) to store the dump. My question is, how can I change the core dump location for these kind of applications without changing ABRT functioning? I was about to rewrite core_pattern to a user directory but I guess ABRT will write all system core dumps in it too, right? So what is the solution?

Every couple weeks, I need to reboot my system. When I do, and enter as root in the terminal, the following message (in some variation) appears: ABRT has detected 3 problem(s). For more info run: abrt-cli list --since 1440594093 I usually ignore it, but I decided to check it out. Entering the suggested command brings the following: id cc91ff6c3e2e76eaf0956435836ad6d48d27bdb5 reason: irq 19: nobody cared (try booting with the "irqpoll" option) time: Thu 27 Aug 2015 01:40:39 PM EDT cmdline: BOOT_IMAGE=/vmlinuz-3.10.0-229.11.1.el7.x86_64 root=/dev/mapper/centos-root ro rd.lvm.lv=centos/swap vconsole.font=latarcyrheb-sun16 rd.lvm.lv=centos/root crashkernel=auto vconsole.keymap=us rhgb quiet LANG=en_US.UTF-8 package: kernel count: 1 Directory: /var/spool/abrt/oops-2015-08-27-13:40:39-663-0 id 35973446166ec36265e0c46ee2b2b553e759fdf0 reason: irq 19: nobody cared (try booting with the "irqpoll" option) time: Wed 26 Aug 2015 09:17:18 AM EDT cmdline: BOOT_IMAGE=/vmlinuz-3.10.0-229.11.1.el7.x86_64 root=/dev/mapper/centos-root ro rd.lvm.lv=centos/swap vconsole.font=latarcyrheb-sun16 rd.lvm.lv=centos/root crashkernel=auto vconsole.keymap=us rhgb quiet LANG=en_US.UTF-8 Directory: /var/spool/abrt/oops-2015-08-26-09:17:17-663-0 Reported: cannot be reported id 49915ba710ac612e102ac910313038528958afa3 reason: irq 19: nobody cared (try booting with the "irqpoll" option) time: Wed 26 Aug 2015 09:08:02 AM EDT cmdline: BOOT_IMAGE=/vmlinuz-3.10.0-229.1.2.el7.x86_64 root=/dev/mapper/centos-root ro rd.lvm.lv=centos/swap vconsole.font=latarcyrheb-sun16 rd.lvm.lv=centos/root crashkernel=auto vconsole.keymap=us rhgb quiet LANG=en_US.UTF-8 package: kernel count: 4 Directory: /var/spool/abrt/oops-2015-08-26-09:08:02-26725-0 Why am I getting these messages? I have not done any debugging because I do not know where to even start. # Linux Kernel: 3.10.0-229.11.1.el7.x86_64 # CentOS Linux release: 7.1.1503 (Core)

I freshly installed Fedora 28 on a laptop. On boot, I get a kernel oops I would very much like to report. However, ABRT recognizes the kernel as tainted with flags GW and thus refuses to report it. If I take a look at the [abrt documentation](http://abrt.readthedocs.io/en/latest/faq.html#what-is-tainted-kernel-and-why-is-my-kernel-tainted) , it is written that W means "a warning has previously been issued by the kernel." whereas G tells me that only GPL-compatible modules are loaded (as expected, I did not install any kernel modules myself). But what exactly does this mean? Has the warning been issued by the kernel to bugzilla? This message really doesn't help me understanding why a freshly installed Linux leaves me with an error I am unable to report ... cat /proc/sys/kernel/tainted also just gives the value 512, i. e. there is only a kernel warning according to the [sysctl documentation](https://github.com/torvalds/linux/blob/master/Documentation/sysctl/kernel.txt) . So how can I find out what exactly happened and why am I not allowed to report it with ABRT? **Edit**: According to [this comment from 2012](https://bugzilla.redhat.com/show_bug.cgi?id=786280#c3) on the RedHat Bugzilla > 'w' means a warning has already occurred. We only care about the first one, which abrt should have already filed. Thus I looked to find anything in the tainted report to find out where, if at all, ABRT reported the "first one" and found [this report on FAF](http://retrace.fedoraproject.org/faf/reports/2147917/) -- however, the kernel is marked as "tainted" as well, so the report will probably not be considered for fixing and I still don't know, why.

I keep getting a warning every time I switch to root. > ABRT has detected 'x' problems(s). For more info run arbt-cli list. And 'arbt-cli list' lists the same problem over and over again: id b34c40c7bb83544557c2f0e9159dac1b6f0fe248 reason: mce: [Hardware Error]: Machine check events logged time: Thu 10 Aug 2017 01:18:58 PM EDT cmdline: BOOT_IMAGE=/vmlinuz-3.10.0-514.el7.x86_64 root=/dev/mapper/cl-root ro crashkernel=auto rd.lvm.lv=cl/root rd.lvm.lv=cl/swap rhgb quiet LANG=en_US.UTF-8 package: kernel uid: 0 (root) count: 1 Directory: /var/spool/abrt/oops-2017-08-10-13:18:58-4298-0 Reported: cannot be reported There was only one time in which there was a different problem that occured: id d51f71a530d663d892e6ad34c2e0fc8908e7b527 reason: Gio.py:171:__call__:Error: g-dbus-error-quark: GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: No such interface 'org.freedesktop.NetworkManager.Settings.Connection' on object at path /org/freedesktop/NetworkManager/Settings/2 (19) time: Wed 09 Aug 2017 10:49:48 PM EDT cmdline: /usr/bin/python /usr/libexec/initial-setup/initial-setup-graphical --no-stdout-log package: initial-setup-gui-0.3.9.36-1.el7.centos uid: 0 (root) count: 1 Directory: /var/spool/abrt/Python-2017-08-09-22:49:48-1072 I do not know what to make of this. I installed CentOS 7 on a Inspiron 7000 50 Gaming. It's brand new, so I don't understand why it would be having hardware problems already.

I'm debugging an issue with python and incron, when I run my script, and then checking the status, it says it has an error. then it said it sent an email to root@localhost, I'm assuming this is at /var/mail/root? When I check that file though, the last update was 10 days ago. Now I'm not sure where I should look for the detailed error message

We have a system (Red Hat Enterprise Linux Server release 6.6) where we occasionally see hung java processes (xalan or fop transformations). These processes just sit there and never complete In /var/log/messages I find entries like this abrt: Saved core dump of pid 48556 (/usr/bin/jdk1.6.0_06/bin/java) to /var/spool/abrt/ccpp-2017-06-01-08:52:40-48556 (341344256 bytes) abrtd: Directory 'ccpp-2017-06-01-08:52:40-48556' creation detected abrtd: Executable '/usr/bin/jdk1.6.0_06/bin/java' doesn't belong to any package and ProcessUnpackaged is set to 'no' abrtd: 'post-create' on '/var/spool/abrt/ccpp-2017-06-01-08:52:40-48556' exited with 1 abrtd: Deleting problem directory '/var/spool/abrt/ccpp-2017-06-01-08:52:40-48556' * Can abrt be used to gather extra information about the issues ? * Is it useful to change ProcessUnpackaged to yes ?

Running a pretty standard Fedora 25 system I expect that the core files of all segfaulting processes are collected by ABRT. But this doesn't seem to be the case. ABRT is enabled: cat /proc/sys/kernel/core_pattern |/usr/libexec/abrt-hook-ccpp %s %c %p %u %g %t %P %I A self-test does work of a simple user segfault works: sleep 100 & kill -11 $! + segmentation fault (core dumped) sleep 100 And a directory containing the core file under /var/spool/abrt is generated (i.e. ccpp-YYYY-MM-DD...). Also the journal records: Jan 01 21:38:12 example.org audit: ANOM_ABEND auid=1000 uid=0 gid=0 ses=3 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=17183 comm="sleep" exe="/usr/bin/sleep" sig=11 Jan 01 21:38:12 example.org abrt-hook-ccpp: Process 17183 (sleep) of user 0 killed by SIGSEGV - dumping core But when an opensshd process segfaults then the abrt hook doesn't get invoked and thus there is no core file. The journal entries for the opensshd core: Jan 01 21:41:46 example.org audit: ANOM_ABEND auid=4294967295 uid=0 gid=0 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 pid=18256 comm="sshd" exe="/usr/sbin/sshd" sig=11 Jan 01 21:41:46 example.org kernel: traps: sshd general protection ip:7f4d8d16ffd1 sp:7ffd42d93ef0 error:0 in libc-2.24.so[7f4d8d0ef000+1bd000] Is this an ABRT bug or a feature? That means is the core file collection for system daemons disabled, by default? And how do I enable it?