Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Description of problem:
This bug is a follow up of bug 1875554. The issue was observed in the supervdsm which uses python-blivet where it holds the unampped multipath device indefinitely.
From the strace output, we can see that the blivet opens the device, tried to read it and then failed with EIO. However, it doesn't care to close it.
===
10078 10:38:25.869889 open("/dev/mapper/36001405097fdbe4d6e04e3b9bdc97014", O_RDONLY <unfinished ...>
10078 10:38:25.870015 <... open resumed>) = 25
10078 10:38:25.870415 lseek(25, 440, SEEK_SET <unfinished ...>
10078 10:38:25.870600 read(25, <unfinished ...>
10078 10:38:25.870759 <... read resumed>0x7f865c0ec984, 4) = -1 EIO (Input/output error)
< -- then jumped to next device without closing the fd 25-->
10078 10:38:25.871192 open("/dev/sda", O_RDONLY <unfinished ...>
===
blivlet is not closing the device if there is an exception while accessing the device.
===
blivet/devicelibs/edd.py
153 def collect_mbrs(devices):
154 """ Read MBR signatures from devices.
155
156 Returns a dict mapping device names to their MBR signatures. It is not
157 guaranteed this will succeed, with a new disk for instance.
158 """
159 mbr_dict = {}
160 for dev in devices:
161 try:
162 fd = os.open(dev.path, os.O_RDONLY)
163 # The signature is the unsigned integer at byte 440:
164 os.lseek(fd, 440, 0)
165 mbrsig = struct.unpack('I', os.read(fd, 4))
166 os.close(fd)
167 except OSError as e:
168 log.warning("edd: error reading mbrsig from disk %s: %s",
169 dev.name, str(e))
170 continue ===> Not closing fd if it fails to access the device and continues with next device
====
Version-Release number of selected component (if applicable):
python-blivet-0.61.15.75-1.el7.noarch
How reproducible:
100%
Steps to Reproduce:
The issue is reproducible in RHV with below steps.
[1] Map a LUN to the server.
[2] Create a partition on this LUN.
[3] Unamp the LUN from the storage.
[4] Fush the cache on the host.
# echo 3 > /proc/sys/vm/drop_caches
[5] Login to RHV-M => click on hosts => Storage devices => sync
Actual results:
Not closing the fd if it fails while reading mbr
Expected results:
It should close the fd correctly if it fails to read the device.
Additional info:
A fix for this https://github.com/storaged-project/blivet/pull/899 is already merged in upstream.
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory (python-blivet bug fix and enhancement update), and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
https://access.redhat.com/errata/RHBA-2020:5032