Bug 1042695

Summary: [abrt] yumex-3.0.13-1.fc19: misc.py:1018:write:IOError: [Errno 5] Erreur d'entrée/sortie
Product: [Fedora] Fedora Reporter: mrblack
Component: yumexAssignee: Tim Lauridsen <tla>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 19CC: acaciosc1, alex.go4more, aloner, anton.clemens.bors, arielnmz, avv.marengoni, balint.szgt, brunno, campbell.bain, dallen, dcharlespyle, deszell, eblix08, fb.commerce, fedor.butikov, fhauva, fukidid, iskenderoguz, j.janovec, joe, kaka.in, KoVadim, mail, matthewdoye, me, nimzosagar, oasookee, patrick.meymat, pavkamlc, pichot.malo, recon0000, serega.belarus, sir.ade, sokol420, taurages, tech, tla
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Unspecified   
URL: https://retrace.fedoraproject.org/faf/reports/bthash/288ace8278544848b6e2c07aea62adb0a7580795
Whiteboard: abrt_hash:515c6d1ec273c6b8fd9d30f5fb32c2de6d0f8865
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-07-24 07:03:45 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
File: backtrace
none
File: environ
none
screenshot none

Description mrblack 2013-12-13 05:23:02 UTC
Version-Release number of selected component:
yumex-3.0.13-1.fc19

Additional info:
reporter:       libreport-2.1.9
cmdline:        /usr/bin/python -E /usr/share/yumex/yum_childtask.py 2 True False /etc/yum.conf kde;skype;kde-testing;playonlinux;fedora;rpmfusion-free-updates;adobe-linux-x86_64;rpmfusion-free;rpmfusion-nonfree-updates;updates;rpmfusion-nonfree;intellinuxgraphics
dso_list:       yum-3.4.3-120.fc19.noarch
executable:     /usr/share/yumex/yum_childtask.py
kernel:         3.11.10-200.fc19.x86_64
runlevel:       N 5
type:           Python
uid:            0

Truncated backtrace:
misc.py:1018:write:IOError: [Errno 5] Erreur d'entrée/sortie

Traceback (most recent call last):
  File "/usr/share/yumex/yum_childtask.py", line 64, in <module>
    my.dispatcher()
  File "/usr/lib/python2.7/site-packages/yumexbackend/yum_server.py", line 1520, in dispatcher
    print errmsg
  File "/usr/lib/python2.7/site-packages/yum/misc.py", line 1018, in write
    self.stream.write(s)
IOError: [Errno 5] Erreur d'entrée/sortie

Local variables in innermost frame:
s: 'Traceback (most recent call last):\n  File "/usr/lib/python2.7/site-packages/yumexbackend/yum_server.py", line 1499, in dispatcher\n    line = sys.stdin.readline().strip(\'\\n\')\nIOError: [Errno 5] Erreur d\'entr\xc3\xa9e/sortie\n'
self: <open file '<stdout>', mode 'w' at 0x7fe68eaef150>

Comment 1 mrblack 2013-12-13 05:23:08 UTC
Created attachment 836131 [details]
File: backtrace

Comment 2 mrblack 2013-12-13 05:23:09 UTC
Created attachment 836132 [details]
File: environ

Comment 3 col 2014-01-05 09:16:12 UTC
i'm getting this too. yumex is quite happy to update existing files but when i attempt to install something new (openbox for example) it hangs and the process has to be killed.

Comment 4 me 2014-01-08 10:11:37 UTC
In my case it happens when dependencies can't be solved. While Yum exits with an error message, Yumex hangs up.

Comment 5 Benjamin Ariel Nava Martinez 2014-01-28 06:40:06 UTC
Mine (sometimes) freezes when "user input" (root auth) is needed and I have to kill it.

Comment 6 Benjamin Ariel Nava Martinez 2014-01-28 06:44:55 UTC
Sorry, for "user input" I meant when yumex asks for confirmation (y/N) for package operations, not authentication.

Comment 7 Benjamin Ariel Nava Martinez 2014-01-28 06:48:56 UTC
This with yumex-3.0.13-1.fc20 and yum-3.4.3-132.fc20 on Fedora 20 x86_64 by the way.

Comment 8 D. Charles Pyle 2014-01-31 16:00:30 UTC
Same just happened to me. I ended up having to kill the application after waiting several minutes with it frozen.

rpm -qa yum*
yum-metadata-parser-1.1.4-9.fc20.x86_64
yum-utils-1.1.31-20.fc20.noarch
yum-3.4.3-132.fc20.noarch
yum-langpacks-0.4.3-1.fc20.noarch
yum-dellsysid-2.2.28-9.fc20.x86_64
yum-plugin-fastestmirror-1.1.31-20.fc20.noarch
yumex-3.0.13-1.fc20.noarch

Comment 9 Szőke Károly 2014-02-03 19:48:57 UTC
Created attachment 858851 [details]
screenshot

when yumex was frozen at this point, I kill the program, then it crashed

Comment 10 D. Charles Pyle 2014-02-03 20:08:48 UTC
I also am seeing this kind of behavior.  There are times when the buttons and information do not show up in the information window that opens up while the updates are in progress.  I have to remember where the button would be located and click there.  Then, I often will see it unfreeze and install the updates in spite of the fact that it does not show anything being done while it happens.  Sometimes, however, even clicking where the button should be will not result in a working update. I then have to kill the application, wait a few seconds, and try again.  This has been going on for a while now.  I am not sure what is causing it.

Comment 11 Joe Zeff 2014-02-04 19:34:47 UTC
I ran yumex this morning and received a kernel update, but the new kmod-nvidia wasn't ready yet.  When yumex was finished and checked again, there were several nvidia-related updates, so I ran them.  When that finished, kmod-nvidia was out, so I tried to update it.  This time, The progress window was blank, and there didn't seem to be any activity so I used x-kill on it and got an abrt icon in my Notification Area.  Before dealing with it, I re-started yumex and it ran just fine.  I don't know if the multiple runs were a factor, but I wanted to add a comment documenting the sequence of events on the off-chance that it might be significant.

Comment 12 Galik 2014-05-31 11:54:49 UTC
I got this when I had to kill the application because it froze/

I can reliably reproduce the problem.

I selected some items to be removed. i then clicked the "Apply" button TWICE and it caused the application to consume 100% cpu.

Comment 13 Tim Lauridsen 2014-07-24 07:03:45 UTC

*** This bug has been marked as a duplicate of bug 881860 ***