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:
(some background: we run several mysql databases with nfs datadirs, and recently upgraded one of our servers to rhel6. After unmounting and remounting the datadir, mysql was starting up with lots of errors about inaccessible tables. Some further troubleshooting found that when mysql starts up it tries to open the ibdata file with O_RDWR|O_CREAT|O_EXCL, and if that call is successful (which would generally indicate that the file didn't exist) it creates a new ibdata file, effectively destroying the relationship between datafiles on disk and the running database.)
Root problem: moving to rhel6, a regression appears to have been introduced, which causes an open() wiht the O_EXCL flag to return incorrect results on file on a newly mounted nfs filesytem.
Version-Release number of selected component (if applicable):
rhel 6.1
How reproducible:
compile attached o_excl.c and follow directions below.
Steps to Reproduce:
(in this case, /db is an nfs filesystem)
[mriddle@db101 src]$ cc -o o_excl o_excl.c
[mriddle@db101 src]$ sudo touch /db/foo; sudo chown mriddle /db/foo
[mriddle@db101 src]$ ./o_excl /db/foo
open() of /db/foo returned -1, not creating new file (this is good)
[mriddle@db101 src]$ sudo umount /db
[mriddle@db101 src]$ sudo mount /db
[mriddle@db101 src]$ ./o_excl /db/foo
open() of /db/foo successful, this is bad!
Actual results:
After mounting an nfs filesystem, an open() that should fail succeeds
Expected results:
open() should fail in this scenario
Additional info:
Looking at the release notes of the most recent kernel package, I found:
2011-07-21 12:00:00
Frantisek Hrbata <fhrbata> [2.6.32-131.10.1.el6]:
- [fs] NFS: Fix NFSv3 exclusive open semantics (Jeff Layton) [719925 694210]
along with this in the errata notes:
This update fixes a regression in which a client would use an UNCHECKED NFS CREATE call when an oen system call was attempted with the O_EXCL|O_CREAT flag combination. An EXCLUSIVE NFS CREATE call should have been used instead to ensure that O_EXCL semantics were preserved. As a result, an application could be led to believe that it had created the file when it was in fact created by anyother application.
I'm installing this package now, but expect it to resolve my issue.
Unfortunately the two bugzilla bugs referenced in the changelog are not visible to me, so when I searched for a similar bug I was unable to find one.