Bug 829161

Summary: Unrecognized variable 'DumpLocation' in '/etc/abrt/abrt.conf'
Product: Red Hat Enterprise Linux 6 Reporter: Gabriel Rocha <grocha>
Component: abrtAssignee: abrt <abrt-devel-list>
Status: CLOSED ERRATA QA Contact: Branislav Náter <bnater>
Severity: low Docs Contact:
Priority: medium    
Version: 6.4CC: anton, barbara.xxx1975, bnater, bojan, bugzilla-2004, ddumas, djuran, dkutalek, dvlasenk, fedoration, fgrose, iprikryl, jmoskovc, kklic, mark, mcermak, mnowak, msvoboda, mtoman, nobody+abrt-devel-list, npajkovs, rvokal, sftw, stephent98, syeghiay
Target Milestone: rcKeywords: TestOnly
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 715456 Environment:
Last Closed: 2013-02-21 07:53:51 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 715456    
Bug Blocks: 782183, 840699    
Attachments:
Description Flags
The default abrt.conf from abrt-2.0.4 none

Description Gabriel Rocha 2012-06-06 06:04:27 UTC
+++ This bug was initially created as a clone of Bug #715456 +++

Description of problem:

These are in /var/log/messages:
Jun 22 15:55:28 fir abrt[4417]: Unrecognized variable 'DumpLocation' in '/etc/abrt/abrt.conf'
Jun 22 15:55:28 fir abrtd: Unrecognized variable 'DumpLocation' in '/etc/abrt/abrt.conf'

Version-Release number of selected component (if applicable):
abrt-2.0.3-1.fc15.x86_64
/etc/abrt/abrt.conf is unmodified.

How reproducible:
Always.

Steps to Reproduce:
1. $ sudo tail -f /var/log/messages
2. $ sleep 1000 &
3. $ kill -6 `pgrep sleep`
  
Actual results:
See above.

Expected results:
Presumably, no such messages.

Additional info:
$ grep DumpLocation /etc/abrt/abrt.conf
DumpLocation = /var/spool/abrt

--- Additional comment from npajkovs on 2011-06-23 04:55:25 EDT ---

I already have a patch for that, but some work needs to be done before I will apply patch.

--- Additional comment from npajkovs on 2011-07-07 06:26:38 EDT ---

Patches which brings Unrecognized variable 'DumpLocation' in '/etc/abrt/abrt.conf' were reverted and it won't be shown in next release.

--- Additional comment from fedoration on 2011-07-16 08:35:14 EDT ---

any ETA for the fix?  I can't get core dumps

abrt frequently causes me more problems than it solves and I'm close to uninstalling it and dealing with crashes the good old fashioned way

--- Additional comment from stephent98 on 2011-07-20 12:43:17 EDT ---

(In reply to comment #3)
> any ETA for the fix?  I can't get core dumps
...

This bug doesn't seem to prevent core dumps from being reported and generated:
abrt-2.0.3-1.fc15.x86_64

Do you get an alert and core dump with this test?
$ sleep 1000 &
$ kill -6 `pgrep sleep`

--- Additional comment from fedoration on 2011-07-20 13:40:13 EDT ---

yes, I get an abrt notification for that, but I don't really care about getting coredumps for contrived tests like that, I want core dumps when my programs crash, and for this:


$ gcc -x c - <<< 'int main() { __builtin_abort(); }'
$ ./a.out
Aborted (core dumped)

I get this in /var/log/messages


Jul 20 18:36:49 moria abrt[24770]: Unrecognized variable 'DumpLocation' in '/etc/abrt/abrt.conf'
Jul 20 18:36:49 moria abrtd: Unrecognized variable 'DumpLocation' in '/etc/abrt/abrt.conf'
Jul 20 18:36:49 moria abrt[24770]: saved core dump of pid 24769 (/dev/shm/a.out) to /var/spool/abrt/ccpp-2011-07-20-18:36:49-24769.new/coredump (237568 bytes)
Jul 20 18:36:49 moria abrtd: Directory 'ccpp-2011-07-20-18:36:49-24769' creation detected
Jul 20 18:36:49 moria abrtd: Corrupted or bad dump /var/spool/abrt/ccpp-2011-07-20-18:36:49-24769 (res:2), deleting

--- Additional comment from stephent98 on 2011-07-20 14:14:02 EDT ---

(In reply to comment #5)
> yes, I get an abrt notification for that, but I don't really care about getting
> coredumps for contrived tests like that, I want core dumps when my programs
> crash, and for this:
> 
> 
> $ gcc -x c - <<< 'int main() { __builtin_abort(); }'
> $ ./a.out
> Aborted (core dumped)
> 
> I get this in /var/log/messages
> 
> 
> Jul 20 18:36:49 moria abrt[24770]: Unrecognized variable 'DumpLocation' in
> '/etc/abrt/abrt.conf'
> Jul 20 18:36:49 moria abrtd: Unrecognized variable 'DumpLocation' in
> '/etc/abrt/abrt.conf'
> Jul 20 18:36:49 moria abrt[24770]: saved core dump of pid 24769
> (/dev/shm/a.out) to /var/spool/abrt/ccpp-2011-07-20-18:36:49-24769.new/coredump
> (237568 bytes)
> Jul 20 18:36:49 moria abrtd: Directory 'ccpp-2011-07-20-18:36:49-24769'
> creation detected
> Jul 20 18:36:49 moria abrtd: Corrupted or bad dump
> /var/spool/abrt/ccpp-2011-07-20-18:36:49-24769 (res:2), deleting

OK, thanks.
You may need to disable the GPG check.

$ cat /etc/abrt/abrt.conf
...
OpenGPGCheck = no
...

This is a related bug:
Bug 699152 - not logged: "Package 'shotwell' isn't signed with proper key\n"

--- Additional comment from stephent98 on 2011-07-20 14:57:38 EDT ---

(In reply to comment #6)
...
> OK, thanks.
> You may need to disable the GPG check.
> 
> $ cat /etc/abrt/abrt.conf
> ...
> OpenGPGCheck = no
> ...
...

That didn't work.

For the test case:
> $ gcc -x c - <<< 'int main() { __builtin_abort(); }'
> $ ./a.out

ProcessUnpackaged needs to be enabled in /etc/abrt/abrt.conf:

-ProcessUnpackaged = no
+ProcessUnpackaged = yes

--- Additional comment from sftw on 2011-08-06 12:18:52 EDT ---

I encountered the same issue when Android's adb crashed. No dump was created, and /var/log/messages included "Corrupted or bad dump <>, deleting".

Changing BOTH:

-OpenGPGCheck = yes
+OpenGPGCheck = no

-ProcessUnpackaged = no
+ProcessUnpackaged = yes

solved the test case using gcc to produce a dump. Just waiting for adb to crash again to confirm a live test.

--- Additional comment from fedoration on 2011-08-14 12:24:22 EDT ---

The man page for abrt.conf says that ProcessUnpackaged=no means abrt will only catch crashes in Fedora packages. I would think that means it would not touch core dumps from my packages, and not try to analyse them and not delete them either.  With ProcessUnpackaged=yes my coredumps are put somewhere under /var/spool and abrt tries to make me report them, which obviously makes no sense for my own software. This is pretty annoying for a software developer.

How do I make abrt just leave my cores the hell alone, and put them somewhere convenient like /var/core/$(id -u) -- do I have to disable abrt completely to do that?

Surely there's some way to have abrt handle Fedora packages, but not handle cores in unknown programs, *and* *not* *delete* *them* either.

--- Additional comment from jmoskovc on 2011-08-14 12:40:19 EDT ---

(In reply to comment #9)
> 
> Surely there's some way to have abrt handle Fedora packages, but not handle
> cores in unknown programs, *and* *not* *delete* *them* either.

If I want to get coredump from a crashing program, I usually do:

$ ulimit -c unlimited

then I get core.<PID> of the crashing program in the cwd even with abrt enabled. What is your usual way to get the coredumps?

--- Additional comment from fedoration on 2011-08-22 07:02:42 EDT ---

(In reply to comment #10)
> (In reply to comment #9)
> > 
> > Surely there's some way to have abrt handle Fedora packages, but not handle
> > cores in unknown programs, *and* *not* *delete* *them* either.
> 
> If I want to get coredump from a crashing program, I usually do:
> 
> $ ulimit -c unlimited
> 
> then I get core.<PID> of the crashing program in the cwd even with abrt
> enabled. What is your usual way to get the coredumps?

I always have no limit on corefile size, and get ./core.PID after editing abrt.conf as described above, but even then abrt still notifies me of a crash (i.e. it is processing non-Fedora packages)

--- Additional comment from bojan on 2011-09-05 06:59:12 EDT ---

Can we get some packages for F-15 built that fix this?

--- Additional comment from npajkovs on 2011-09-05 07:21:55 EDT ---

I'm going to roll an update

--- Additional comment from bojan on 2011-09-05 07:35:33 EDT ---

(In reply to comment #13)
> I'm going to roll an update

Thank you.

--- Additional comment from updates on 2011-09-05 11:01:28 EDT ---

abrt-2.0.3-2.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/abrt-2.0.3-2.fc15

--- Additional comment from bojan on 2011-09-05 19:50:37 EDT ---

Just FYI, still getting this with the update:

$ rpm -qf -V /var/spool/abrt
.....UGM.    /var/run/abrt

Not sure why...

--- Additional comment from jmoskovc on 2011-09-06 03:29:06 EDT ---

(In reply to comment #16)
> Just FYI, still getting this with the update:
> 
> $ rpm -qf -V /var/spool/abrt
> .....UGM.    /var/run/abrt
> 
> Not sure why...

I see this too even though the permissions and attributes are the same as in the spec file, maybe bug in rpm -> will check it with rpm devels.

--- Additional comment from npajkovs on 2011-09-06 05:36:10 EDT ---

(In reply to comment #16)
> Just FYI, still getting this with the update:
> 
> $ rpm -qf -V /var/spool/abrt
> .....UGM.    /var/run/abrt
> 
> Not sure why...

Me neither, but I'm going to investigate more deeply.

/var/run/abrt should be /run/abrt/ because of systemd

--- Additional comment from updates on 2011-09-06 20:13:30 EDT ---

Package abrt-2.0.3-2.fc15:
* should fix your issue,
* was pushed to the Fedora 15 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing abrt-2.0.3-2.fc15'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/abrt-2.0.3-2.fc15
then log in and leave karma (feedback).

--- Additional comment from updates on 2011-09-09 09:24:29 EDT ---

abrt-2.0.3-3.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/abrt-2.0.3-3.fc15

--- Additional comment from updates on 2011-09-13 12:02:13 EDT ---

abrt-2.0.3-4.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/abrt-2.0.3-4.fc15

--- Additional comment from updates on 2011-09-29 19:25:48 EDT ---

abrt-2.0.3-4.fc15 has been pushed to the Fedora 15 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 1 Gabriel Rocha 2012-06-06 06:12:37 UTC
Cloned from the upstream bug as it affects 6.3 also.

Comment 2 Jiri Moskovcak 2012-06-07 15:01:01 UTC
I can't reproduce this on a clean install so my guess is a problem with stalled .conf file. Please check /etc/abrt dir for any *.rpmnew files.

Comment 6 Jiri Moskovcak 2012-08-03 13:24:07 UTC
That's old configuration file (ABRT1), it this is rhel6.2 then it should have ABRT2 with different config file. To me it seems like messed update. Can you please get the output of:

$ rpm -qa | grep abrt
$ rpm -qa | grep libreport

Comment 8 Jiri Moskovcak 2012-08-06 07:24:11 UTC
Created attachment 602449 [details]
The default abrt.conf from abrt-2.0.4

Attaching the original abrt.conf file extracted from abrt-2.0.4-14.el6.x86_64.rpm which should fix the problem.

Comment 16 Jiri Moskovcak 2012-10-18 08:27:17 UTC
As I mentioned in comment#13 it was probably a problem during the update from the older version resulting in a stalled configuration file which I'm not able to reproduce. So to test of this bug should cover updating from abrt-1.X to abrt-2.X

Comment 18 Branislav Náter 2012-12-19 17:36:05 UTC
Issue has been verified with following scenario:

1. RHEL6.1 system with abrt-1.1.16-3.el6 has been deployed
2. invoke program crash (create crash dir)
 - Verify that there are no unexpected errors in log files
3. upgrade system to RHEL 6.3 (abrt-2.0.8-6.el6)
4. invoke program crash (create crash dir)
 - Verify that there are no unexpected errors in log files, especially DumpLocation error.
5. set custom dump location in abrt.conf and invoke program crash
 - Verify that there are no unexpected errors in log files, especially DumpLocation error.

During this procedure, no messages regarding DumpLocation error have been spotted in /var/log/messages log.

Comment 19 errata-xmlrpc 2013-02-21 07:53:51 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2013-0290.html