Bug 1038731 - Queuing a gzipped file via "Custom Core Location" hangs indefinitely - manually gunzip and resubmit works
Summary: Queuing a gzipped file via "Custom Core Location" hangs indefinitely - manual...
Status: CLOSED ERRATA
Alias: None
Product: Fedora EPEL
Classification: Fedora
Component: retrace-server
Version: el6
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Michal Toman
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords: TestCaseProvided
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-12-05 16:56 UTC by Dave Wysochanski
Modified: 2015-03-23 00:42 UTC (History)
3 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2014-08-15 18:58:07 UTC


Attachments (Terms of Use)

Description Dave Wysochanski 2013-12-05 16:56:25 UTC
Description of problem:
I've noticed we're getting a fair number of tasks which hang with a status of "Post-processing downloaded file".  These tasks all have the following in common:
a) they are a local file and were submitted via "Custom Core Location"
b) they are gzipped files

It seems if you manually gunzip the file, then submit via "Custom Core Location" it works fine.  I also checked and the gunzip exits with a 0, so it's not the gunzip failing.


Version-Release number of selected component (if applicable):
retrace-server-1.10-1.el6.noarch

How reproducible:
It seems everytime if you submit a gzipped file.

Steps to Reproduce:
1. submit a gzipped local file vmcore via "Custom Core Location" from web interface
2. wait for completion (does not complete)

Actual results:
Stuck at "Post-processing downloaded file"

Expected results:
Either error out or complete properly.


Additional info:
I have an example I will share of a gzipped vmcore vs non-gzipped core.

Comment 2 Michal Toman 2014-02-26 09:15:37 UTC
Fixed in upstream

commit 4d932a81691542ab3dc25b78167ef3868eea4e33
Author: Michal Toman <mtoman@redhat.com>
Date:   Tue Feb 25 17:14:32 2014 +0100

    only hardlink unpacked vmcores
    
    Signed-off-by: Michal Toman <mtoman@redhat.com>

Comment 3 Fedora Update System 2014-02-27 13:46:50 UTC
retrace-server-1.11-1.el6 has been submitted as an update for Fedora EPEL 6.
https://admin.fedoraproject.org/updates/retrace-server-1.11-1.el6

Comment 5 Dave Wysochanski 2014-02-28 15:34:51 UTC
I did some testing of this bug fix.  Looks fixed to me!

Comment 7 Fedora Update System 2014-03-01 07:11:50 UTC
Package retrace-server-1.11-1.el6:
* should fix your issue,
* was pushed to the Fedora EPEL 6 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=epel-testing retrace-server-1.11-1.el6'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0687/retrace-server-1.11-1.el6
then log in and leave karma (feedback).

Comment 8 Fedora Update System 2014-07-31 11:52:49 UTC
retrace-server-1.12-2.el6 has been submitted as an update for Fedora EPEL 6.
https://admin.fedoraproject.org/updates/retrace-server-1.12-2.el6

Comment 10 Fedora Update System 2014-08-15 18:58:07 UTC
retrace-server-1.12-2.el6 has been pushed to the Fedora EPEL 6 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.