Bug 692064 - abrt fails to fetch debuginfo files
Summary: abrt fails to fetch debuginfo files
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: abrt
Version: 15
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Jiri Moskovcak
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 692806 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-03-30 10:45 UTC by Tim Waugh
Modified: 2015-02-01 22:53 UTC (History)
13 users (show)

Fixed In Version: abrt-2.0.1-2.fc15
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-04-26 16:15:44 UTC


Attachments (Terms of Use)
abrt.txt (28.65 KB, text/plain)
2011-03-30 10:45 UTC, Tim Waugh
no flags Details
abrt.txt (17.97 KB, text/plain)
2011-03-31 12:37 UTC, Tim Waugh
no flags Details

Description Tim Waugh 2011-03-30 10:45:28 UTC
Created attachment 488734 [details]
abrt.txt

Description of problem:
While trying to report a crash, abrt fails to install debuginfo files and prevents me reporting to bugzilla as a result.

Version-Release number of selected component (if applicable):

abrt-libs-2.0.0-2.fc15.x86_64
abrt-addon-ccpp-2.0.0-2.fc15.x86_64
abrt-plugin-logger-2.0.0-2.fc15.x86_64
abrt-2.0.0-2.fc15.x86_64
abrt-addon-kerneloops-2.0.0-2.fc15.x86_64
abrt-addon-python-2.0.0-2.fc15.x86_64
abrt-gui-2.0.0-2.fc15.x86_64
abrt-plugin-bugzilla-2.0.0-2.fc15.x86_64
abrt-desktop-2.0.0-2.fc15.x86_64

How reproducible:
100%

Steps to Reproduce:
1.Make something crash :-)
2.Follow the abrt dialogs
  
Actual results:
The 'Analyzing' dialog contains the attached text.

Comment 1 Tim Waugh 2011-03-30 10:46:22 UTC
$ rpm -qa | grep abrt | xargs rpm -V
.....UGM.    /var/run/abrt

This persists even after 'yum reinstall abrt'.

I am running in permissive mode:

$ getenforce 
Permissive

Comment 2 Jiri Moskovcak 2011-03-30 11:08:37 UTC
can you please post output of: 

$  ls -l /var/cache | grep abrt

Comment 3 Jiri Moskovcak 2011-03-30 11:12:45 UTC
and also:

$ ls -l /var/cache/abrt-di/

Comment 4 Fedora Update System 2011-03-30 16:43:27 UTC
abrt-2.0.0-3.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/abrt-2.0.0-3.fc15

Comment 5 Fedora Update System 2011-03-31 03:52:44 UTC
Package abrt-2.0.0-3.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.0-3.fc15'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/abrt-2.0.0-3.fc15
then log in and leave karma (feedback).

Comment 6 Tim Waugh 2011-03-31 12:18:54 UTC
I'm afraid it does not fix the issue.

Comment 7 Jiri Moskovcak 2011-03-31 12:26:50 UTC
Are you sure the error output is the same? Can you send me the output of ls command I asked for in c#2 and c#3.

Comment 8 Tim Waugh 2011-03-31 12:37:36 UTC
[twaugh@worm ~]$ ls -l /var/cache | grep abrt
drwxrwxr-x.  3 abrt abrt 4096 Mar 30 17:33 abrt-di
[twaugh@worm ~]$ ls -l /var/cache/abrt-di/
total 4
drwxrwxr-x. 4 abrt abrt 4096 Mar 25 10:17 usr

I'll attach the error output (it's from a different crash report this time).

Comment 9 Tim Waugh 2011-03-31 12:37:56 UTC
Created attachment 489064 [details]
abrt.txt

Comment 10 Jiri Moskovcak 2011-04-01 13:44:08 UTC
*** Bug 692806 has been marked as a duplicate of this bug. ***

Comment 11 Jiri Moskovcak 2011-04-01 13:55:51 UTC
Seems like we have some problems with upgrading from previous ABRT which uses different user/group for /var/cache/abrt-di/*, removing the old content of /var/cache/abrt-di/ works for me, you can try it as a workaround.

Comment 12 Vlad 2011-04-02 09:10:11 UTC
I had the same issue, but 

>removing the old content of /var/cache/abrt-di/ works for me, you can try it as a workaround.

Helped me.

Comment 13 Fedora Update System 2011-04-04 14:02:52 UTC
abrt-2.0.0-4.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/abrt-2.0.0-4.fc15

Comment 14 Fedora Update System 2011-04-05 20:20:37 UTC
Package abrt-2.0.0-4.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.0-4.fc15'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/abrt-2.0.0-4.fc15
then log in and leave karma (feedback).

Comment 15 Steve Tyler 2011-04-06 22:34:53 UTC
This is occurring with abrt-2.0.0-4.fc15.x86_64:
cpio: ./usr/lib/debug: Cannot change mode to rwxr-xr-x: Operation not permitted

$ ls -l /var/cache | grep abrt
drwxrwxr-x.  3 abrt abrt 4096 Mar 31 05:36 abrt-di

$ ls -l /var/cache/abrt-di/
total 4
drwxrwxr-x. 4 abrt abrt 4096 Mar 30 15:29 usr

After quitting abrt-gui, running "sudo rm -r abrt-di/" in /var/cache/, and rerunning abrt-gui, I got a Python traceback.

Further, "/var/cache/abrt-di/" is not recreated.
[joeblow@fir ~]$ ls -lF /var/cache | grep abrt
[joeblow@fir ~]$ 

selinux is enforcing.

Analyzing coredump '/home/joeblow/.abrt/spool/ccpp-2011-04-04-11:08:00-1582/coredump'
Coredump references 136 debuginfo files, 95 of them are not installed
Could not parse metalink https://mirrors.fedoraproject.org/metalink?repo=updates-released-debug-f15&arch=x86_64 error was 
No repomd file
Looking for needed packages in repositories
Can't find packages for 4 debuginfo files
Packages to download: 61
Downloading 201.63Mb, installed size: 923.72Mb
Traceback (most recent call last):
  File "/usr/bin/abrt-action-install-debuginfo.py", line 476, in <module>
    result = downloader.download(missing)
  File "/usr/bin/abrt-action-install-debuginfo.py", line 262, in download
    os.makedirs(self.cachedir)
  File "/usr/lib64/python2.7/os.py", line 157, in makedirs
    mkdir(name, mode)
OSError: [Errno 13] Permission denied: '/var/cache/abrt-di'

Comment 16 Steve Tyler 2011-04-08 11:43:40 UTC
(In reply to comment #15)
> After quitting abrt-gui, running "sudo rm -r abrt-di/" in /var/cache/, and
> rerunning abrt-gui, I got a Python traceback.

For the record:
Bug 694305 - [abrt] abrt-addon-ccpp-2.0.0-4.fc15: os.py:157:makedirs:OSError: [Errno 13] Permission denied: '/var/cache/abrt-di'

Comment 17 Jiri Moskovcak 2011-04-12 16:00:32 UTC
*** Bug 694305 has been marked as a duplicate of this bug. ***

Comment 18 Fedora Update System 2011-04-15 15:01:30 UTC
abrt-2.0.0-5.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/abrt-2.0.0-5.fc15

Comment 19 Christian Kujau 2011-04-18 19:44:00 UTC
With abrt-2.0.0-5.fc15.x86_64, abrtd still fails with:

------------------
Analyzing coredump '/home/christian/.abrt/spool/ccpp-2011-04-18-12:35:14-4614/coredump'
Traceback (most recent call last):
  File "/usr/bin/abrt-action-install-debuginfo.py", line 410, in <module>
    fin = open(core)
IOError: [Errno 13] Permission denied: 'build_ids'
------------------

Btw, why does abrtd always bug me with:

------------------
Need writable directory, but '/var/spool/abrt/ccpp-2011-04-18-11:44:38-30348' is not writable. Move it to '/home/christian/.abrt/spool' and operate on the moved copy?
------------------

# ls -ldZ /var/spool/abrt/
drwxr-xr-x. abrt abrt system_u:object_r:abrt_var_cache_t:s0 /var/spool/abrt/

Comment 20 Jiri Moskovcak 2011-04-19 11:34:02 UTC
Can you please post output of:

$ ls -l /home/christian/.abrt/spool/ccpp-2011-04-18-12:35:14-4614/

Comment 21 Fedora Update System 2011-04-20 13:24:18 UTC
abrt-2.0.1-1.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/abrt-2.0.1-1.fc15

Comment 22 Fedora Update System 2011-04-21 16:40:45 UTC
abrt-2.0.1-2.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/abrt-2.0.1-2.fc15

Comment 23 Fedora Update System 2011-04-26 16:08:01 UTC
abrt-2.0.1-2.fc15 has been pushed to the Fedora 15 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 24 Christian Kujau 2011-04-27 22:24:15 UTC
abrt-2.0.1-2.fc15.x86_64, ABRT stills asks me:

  > Need writable directory, but '/var/spool/abrt/ccpp-2011-04-27-15:14:06-2198'
  > is not writable. Move it to '/home/christian/.abrt/spool' and operate on 
  > the moved copy?

$ ls -la /var/spool/abrt/ccpp-2011-04-27-15:14:06-2198
total 284
drwxr-x---.  2 abrt christian   4096 Apr 27 15:14 .
drwxr-xr-x. 10 abrt abrt        4096 Apr 27 15:14 ..
-rw-r-----.  1 abrt christian      4 Apr 27 15:14 analyzer
-rw-r-----.  1 abrt christian      6 Apr 27 15:14 architecture
-rw-r-----.  1 abrt christian      3 Apr 27 15:14 cmdline
-rw-r-----.  1 abrt christian      6 Apr 27 15:14 component
-rw-r-----.  1 abrt christian 528384 Apr 27 15:14 coredump
-rw-r-----.  1 abrt christian      1 Apr 27 15:14 count
-rw-r-----.  1 abrt christian   1748 Apr 27 15:14 dsos
-rw-r-----.  1 abrt christian   1594 Apr 27 15:14 environ
-rw-r-----.  1 abrt christian     12 Apr 27 15:14 executable
-rw-r-----.  1 abrt christian     20 Apr 27 15:14 hostname
-rw-r-----.  1 abrt christian     31 Apr 27 15:14 kernel
-rw-r-----.  1 abrt christian   2787 Apr 27 15:14 maps
-rw-r-----.  1 abrt christian     28 Apr 27 15:14 os_release
-rw-r-----.  1 abrt christian     32 Apr 27 15:14 package
-rw-r-----.  1 abrt christian     53 Apr 27 15:14 reason
-rw-r-----.  1 abrt christian     10 Apr 27 15:14 time
-rw-r-----.  1 abrt christian      3 Apr 27 15:14 uid
-rw-r-----.  1 abrt christian     10 Apr 27 15:14 username
-rw-r-----.  1 abrt christian     40 Apr 27 15:14 uuid

$ ls -la /home/christian/.abrt/spool/ccpp-2011-04-27-15:14:06-2198
total 296
drwxr-x---. 2 christian christian   4096 Apr 27 15:18 .
drwx--x--x. 6 christian christian   4096 Apr 27 15:18 ..
-rw-------. 1 christian christian      4 Apr 27 15:14 analyzer
-rw-------. 1 christian christian      6 Apr 27 15:14 architecture
-rw-------. 1 christian christian    287 Apr 27 15:18 build_ids
-rw-------. 1 christian christian      3 Apr 27 15:14 cmdline
-rw-------. 1 christian christian      4 Apr 27 15:18 comment
-rw-------. 1 christian christian      6 Apr 27 15:14 component
-rw-------. 1 christian christian 528384 Apr 27 15:14 coredump
-rw-------. 1 christian christian      1 Apr 27 15:14 count
-rw-------. 1 christian christian   1748 Apr 27 15:14 dsos
-rw-------. 1 christian christian   1594 Apr 27 15:14 environ
-rw-------. 1 christian christian    448 Apr 27 15:18 event_log
-rw-------. 1 christian christian     12 Apr 27 15:14 executable
-rw-------. 1 christian christian     20 Apr 27 15:14 hostname
-rw-------. 1 christian christian     31 Apr 27 15:14 kernel
-rw-------. 1 christian christian   2787 Apr 27 15:14 maps
-rw-------. 1 christian christian     28 Apr 27 15:14 os_release
-rw-------. 1 christian christian     32 Apr 27 15:14 package
-rw-------. 1 christian christian     53 Apr 27 15:14 reason
-rw-------. 1 christian christian     10 Apr 27 15:14 time
-rw-------. 1 christian christian      3 Apr 27 15:14 uid
-rw-------. 1 christian christian     10 Apr 27 15:14 username
-rw-------. 1 christian christian     40 Apr 27 15:14 uuid


All files are SELinux tagged with "system_u:object_r:abrt_var_cache_t:s0" in /var/spool/abrt but tagged "unconfined_u:object_r:user_home_t:s0" in /home/christian/.abrt/spool.


Agreeing to the question above, abrt tries to continue, but fails:

Analyzing coredump '/home/christian/.abrt/spool/ccpp-2011-04-27-15:14:06-2198/coredump'
Traceback (most recent call last):
  File "/usr/bin/abrt-action-install-debuginfo.py", line 410, in <module>
    fin = open(core)
IOError: [Errno 13] Permission denied: 'build_ids'


I installed the system from an FC15-Alpha ISO which has now been updated to latest FC15 packages (and rebooted). Linux kernel package is different, running 2.6.39-0.rc5.git0.0.fc16.x86_64 at the moment.

Comment 25 Christian Kujau 2011-06-16 08:25:40 UTC
....erm, ping? It's still there in FC15 - should I open a new bug report?

Comment 26 Jiri Moskovcak 2011-06-16 08:43:34 UTC
(In reply to comment #25)
> ....erm, ping? It's still there in FC15 - should I open a new bug report?

I'm not able to reproduce this, does it happen even for new crashes?

Comment 27 Christian Kujau 2011-06-16 21:19:45 UTC
Yes, it happened to me for a new crash yesterday. I've reprodoced it just now (e.g. crash an application by sending signal 6, ABRT pops up to do its job):

> Need writable directory, but '/var/spool/abrt/ccpp-2011-06-16-14:07:19-3041'
> is not writable. Move it to '/home/christian/.abrt/spool' and operate on the
> moved copy?

----------------------------------------------
$ ls -ldZ /var/spool/abrt/ccpp-2011-06-16-14:07:19-3041
ls: cannot access /var/spool/abrt/ccpp-2011-06-16-14:07:19-3041: No such file or directory
$ ls -ldZ /var/spool/abrt/
drwxr-xr-x. abrt abrt system_u:object_r:abrt_var_cache_t:s0 /var/spool/abrt/

$ ls -ldZ /home/christian/.abrt/spool/ccpp-2011-06-16-14\:07\:19-3041/
drwxr-x---. christian christian unconfined_u:object_r:user_home_t:s0 /home/christian/.abrt/spool/ccpp-2011-06-16-14:07:19-3041/
$ ls -ldZ /home/christian/.abrt/spool/
drwx--x--x. christian christian unconfined_u:object_r:user_home_t:s0 /home/christian/.abrt/spool/
----------------------------------------------

I click "OK" and "Local GNU debugger" but unfortunately today it won't even advance any further than:

> Analyzing coredump 'coredump'
> Can't open build_ids: [Errno 13] Permission denied: 'build_ids'

Should I open a new report for this? Or do I have to restorecon(8) something?

Comment 28 Steve Tyler 2011-06-16 23:51:03 UTC
(In reply to comment #27)
...
> > Analyzing coredump 'coredump'
> > Can't open build_ids: [Errno 13] Permission denied: 'build_ids'
> 
> Should I open a new report for this? Or do I have to restorecon(8) something?

You might be able to eliminate selinux as the problem by setting
SELINUX=permissive
in /etc/selinux/config
and restarting.

BTW, for simulating crashes, I use:
$ sleep 1000 &
$ kill -6 <pid-of-sleep-process>

Comment 29 Paul DeStefano 2012-03-26 21:57:50 UTC
I get the same result from the localDebug process on a fresh F16 install (so it's not /var.  But, I think the original bug might be different, so I'll open a new bug.


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