Bug 249387 - 'I/O operation on closed file' in rhn.transports.File instance
'I/O operation on closed file' in rhn.transports.File instance
Status: CLOSED CURRENTRELEASE
Product: Red Hat Satellite 5
Classification: Red Hat
Component: API (Show other bugs)
500
All Linux
low Severity low
: ---
: ---
Assigned To: Jan Pazdziora
Corey Welton
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-07-24 05:08 EDT by Jan Pazdziora
Modified: 2008-04-14 17:16 EDT (History)
2 users (show)

See Also:
Fixed In Version: sat501
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-08-29 11:30:11 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jan Pazdziora 2007-07-24 05:08:38 EDT
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 2007-07-24 06:17:19 EDT
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 2007-07-24 06:20:42 EDT
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 2007-07-25 03:34:04 EDT
Fix committed to SVN, branch RELEASE-5.0, revision 118566, and trunk, revision
118567.
Comment 4 Jan Pazdziora 2007-08-02 16:36:05 EDT
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 11:31:25 EDT
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 11:08:07 EDT
RELEASE_PENDING
Comment 9 Brandon Perkins 2008-04-14 17:16:05 EDT
Removed Bug 249387 blocks bug 437059.

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