Bug 715456 - Unrecognized variable 'DumpLocation' in '/etc/abrt/abrt.conf'
Summary: Unrecognized variable 'DumpLocation' in '/etc/abrt/abrt.conf'
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: abrt
Version: 15
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Nikola Pajkovsky
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 829161
TreeView+ depends on / blocked
 
Reported: 2011-06-22 23:03 UTC by Steve Tyler
Modified: 2014-02-02 22:15 UTC (History)
19 users (show)

Fixed In Version: abrt-2.0.3-4.fc15
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 829161 (view as bug list)
Environment:
Last Closed: 2011-09-29 23:26:23 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Steve Tyler 2011-06-22 23:03:16 UTC
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

Comment 1 Nikola Pajkovsky 2011-06-23 08:55:25 UTC
I already have a patch for that, but some work needs to be done before I will apply patch.

Comment 2 Nikola Pajkovsky 2011-07-07 10:26:38 UTC
Patches which brings Unrecognized variable 'DumpLocation' in '/etc/abrt/abrt.conf' were reverted and it won't be shown in next release.

Comment 3 Jonathan Wakely 2011-07-16 12:35:14 UTC
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

Comment 4 Steve Tyler 2011-07-20 16:43:17 UTC
(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`

Comment 5 Jonathan Wakely 2011-07-20 17:40:13 UTC
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

Comment 6 Steve Tyler 2011-07-20 18:14:02 UTC
(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"

Comment 7 Steve Tyler 2011-07-20 18:57:38 UTC
(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

Comment 8 Lee Clemens 2011-08-06 16:18:52 UTC
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.

Comment 9 Jonathan Wakely 2011-08-14 16:24:22 UTC
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.

Comment 10 Jiri Moskovcak 2011-08-14 16:40:19 UTC
(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?

Comment 11 Jonathan Wakely 2011-08-22 11:02:42 UTC
(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)

Comment 12 Bojan Smojver 2011-09-05 10:59:12 UTC
Can we get some packages for F-15 built that fix this?

Comment 13 Nikola Pajkovsky 2011-09-05 11:21:55 UTC
I'm going to roll an update

Comment 14 Bojan Smojver 2011-09-05 11:35:33 UTC
(In reply to comment #13)
> I'm going to roll an update

Thank you.

Comment 15 Fedora Update System 2011-09-05 15:01:28 UTC
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

Comment 16 Bojan Smojver 2011-09-05 23:50:37 UTC
Just FYI, still getting this with the update:

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

Not sure why...

Comment 17 Jiri Moskovcak 2011-09-06 07:29:06 UTC
(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.

Comment 18 Nikola Pajkovsky 2011-09-06 09:36:10 UTC
(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

Comment 19 Fedora Update System 2011-09-07 00:13:30 UTC
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).

Comment 20 Fedora Update System 2011-09-09 13:24:29 UTC
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

Comment 21 Fedora Update System 2011-09-13 16:02:13 UTC
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

Comment 22 Fedora Update System 2011-09-29 23:25:48 UTC
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.


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