Bug 249387

Summary:	'I/O operation on closed file' in rhn.transports.File instance
Product:	Red Hat Satellite 5	Reporter:	Jan Pazdziora (Red Hat) <jpazdziora>
Component:	API	Assignee:	Jan Pazdziora (Red Hat) <jpazdziora>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Corey Welton <cwelton>
Severity:	low	Docs Contact:
Priority:	low
Version:	500	CC:	cperry, rhn-bugs
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:	sat501	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2007-08-29 15:30:11 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Jan Pazdziora (Red Hat) 2007-07-24 09:08:38 UTC

Description of problem:

When yum fetches repo data from the Satellite, the following error messages
appear in the /var/log/httpd/error_log:

Exception exceptions.ValueError: 'I/O operation on closed file' in <bound method
File.__del__ of <rhn.transports.File instance at 0xb765cacc>> ignored

Exception exceptions.ValueError: 'I/O operation on closed file' in <bound method
File.__del__ of <rhn.transports.File instance at 0xb75b486c>> ignored

Exception exceptions.ValueError: 'I/O operation on closed file' in <bound method
File.__del__ of <rhn.transports.File instance at 0xb765c9ac>> ignored

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

Satellite 5.0.0, I believe I've already seen it on 4.2.

How reproducible:

Deterministic.

Steps to Reproduce:
1. Run yum check-update.
2. Watch the error_log.
  
Actual results:

The error message about 'I/O operation on closed file'.

Expected results:

No error message.

Additional info:

The initial thought was that this error is somehow related to bug 247156. It
does not seem to be but as I've spent quite some tome investigating the code, I
have a fix in place. That's why I'm putting this in as an exception for sat-5.0.1.

Comment 1 Jan Pazdziora (Red Hat) 2007-07-24 10:17:19 UTC

Here's the result of the investigation:

The Repository.repodata method in /usr/share/rhn/server/rhnRepository.py calls

    output = rpclib.File(output, name=file_name)

The rpclib.File is the same as transports.File, and the output parameter passed
to the File constructor is of the type common.rhnCache.ReadLockedFile. The
transports.File objects is then processed through apacheRequest's response and
response_file, and response_file calls

    response.close()

And since the transports.File's constructor did

    self.close = file_obj.close

the ReadLockedFile's close is directly called.

And the close is called again in transports.File's desctructor.

Comment 2 Jan Pazdziora (Red Hat) 2007-07-24 10:20:42 UTC

We can handle the problem at the rhnCache's level, by allowing multiple calls to
the close method:

Index: rhnCache.py
===================================================================
--- rhnCache.py (revision 118530)
+++ rhnCache.py (working copy)
@@ -160,11 +160,12 @@
         self.closed = False
 
     def close(self):
-        self.close_fd()
+        if not self.closed:
+            self.close_fd()
 
-        _unlock(self.fd.fileno())
-        self.fd.close()
-        self.closed = True
+            _unlock(self.fd.fileno())
+            self.fd.close()
+            self.closed = True
 
 #    def __del__(self):
 #        if not self.closed:

Another possibility is to get rid of the

    self.close = file_obj.close

in transports.File, make close a proper method there, and set the flag that the
close was called in transports.File.

Comment 3 Jan Pazdziora (Red Hat) 2007-07-25 07:34:04 UTC

Fix committed to SVN, branch RELEASE-5.0, revision 118566, and trunk, revision
118567.

Comment 4 Jan Pazdziora (Red Hat) 2007-08-02 20:36:05 UTC

Moving ON_QA because:

Satellite 5.0.1-1 and Proxy 5.0.1-1 are now available on webqa hosted
channels.  Satellite 5.0.1-1 ISOs are now available.

Comment 5 Corey Welton 2007-08-03 15:31:25 UTC

QA Verified - running 'yum check-update' on a RHEL5 system against a 501
satellite results in no errors appearing in /var/log/httpd/error_log

Comment 6 Corey Welton 2007-08-27 15:08:07 UTC

RELEASE_PENDING

Comment 9 Brandon Perkins 2008-04-14 21:16:05 UTC

Removed Bug 249387 blocks bug 437059.