RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 829161 - Unrecognized variable 'DumpLocation' in '/etc/abrt/abrt.conf'
Summary: Unrecognized variable 'DumpLocation' in '/etc/abrt/abrt.conf'
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: abrt
Version: 6.4
Hardware: All
OS: Linux
medium
low
Target Milestone: rc
: ---
Assignee: abrt
QA Contact: Branislav Náter
URL:
Whiteboard:
Depends On: 715456
Blocks: 782183 840699
TreeView+ depends on / blocked
 
Reported: 2012-06-06 06:04 UTC by Gabriel Rocha
Modified: 2018-11-30 22:06 UTC (History)
25 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of: 715456
Environment:
Last Closed: 2013-02-21 07:53:51 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
The default abrt.conf from abrt-2.0.4 (572 bytes, application/octet-stream)
2012-08-06 07:24 UTC, Jiri Moskovcak
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2013:0290 0 normal SHIPPED_LIVE abrt, libreport and btparser bug fix and enhancement update 2013-02-20 20:55:47 UTC

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


Note You need to log in before you can comment on or make changes to this bug.