Description of problem: RHEL4/5 has the following flag definition #define O_ATOMICLOOKUP 02000000 /* do atomic file lookup */ while glibc 2.7 requires #define O_CLOEXEC 02000000 /* set close_on_exec */ This means that a glibc 2.7 open call may (very often) fail on RHEL5 or RHEL4. This holds for chrooted Fedora 8 systems for example as well as future RHEL6 builds on a RHEL5 machine. Statically built binaries from F8 will fail as well. Version-Release number of selected component (if applicable): any How reproducible: very often Steps to Reproduce: 1.setup an F8 chroot on RHEL5 2.Do something in the F8 chroot until you hit unknown error 530 or just some strange failure (like su not working due to /etc/passwd not opening due to error 530. 3. Actual results: Unknown error 530 or even more obfuscated open failures Expected results: Forward ABI compatibility with glibc Additional info: Bugzilla at glibc where this is being discussed: http://sourceware.org/bugzilla/show_bug.cgi?id=5227 Various random "unknown error 530" encounters where users have no idea what this error means and that it is a kernel/glibc ABI incompatibility http://www.google.com/search?q=%22Unknown+error+530%22 This bug is quite hard to track down, as o it is non-deterministic o the error message is not helpful at all ("Unknown error 530") o Quite often there is no errno returned at all (like when pam or nss try to access files and fail)
(In reply to comment #0) > RHEL4/5 has the following flag definition > #define O_ATOMICLOOKUP 02000000 /* do atomic file lookup */ That was only half true (e.g. only for RHEL5) - in order to not confuse people reading this here is the full story: RHEL3/RHEL4 had O_ATOMICLOOKUP defined as 01000000 and RHEL5 shifted it a bit higher to make space for O_NOATIME: el3-i386: /usr/include/asm/fcntl.h:#define O_ATOMICLOOKUP 01000000 /* do atomic file lookup */ el3-x86_64: /usr/include/asm-i386/fcntl.h:#define O_ATOMICLOOKUP 01000000 /* do atomic file lookup */ el3-x86_64: /usr/include/asm-x86_64/fcntl.h:#define O_ATOMICLOOKUP 1000000 el4-i386: /usr/include/asm/fcntl.h:#define O_ATOMICLOOKUP 01000000 /* do atomic file lookup */ el4-x86_64: /usr/include/asm-i386/fcntl.h:#define O_ATOMICLOOKUP 01000000 /* do atomic file lookup */ el4-x86_64: /usr/include/asm-x86_64/fcntl.h:#define O_ATOMICLOOKUP 1000000 el5-i386: /usr/include/asm-generic/fcntl.h:#define O_NOATIME 01000000 el5-i386: /usr/include/asm-generic/fcntl.h:#define O_ATOMICLOOKUP 02000000 /* do atomic file lookup */ el5-x86_64: /usr/include/asm-generic/fcntl.h:#define O_NOATIME 01000000 el5-x86_64: /usr/include/asm-generic/fcntl.h:#define O_ATOMICLOOKUP 02000000 /* do atomic file lookup */ Still this shift was not enough as glibc 2.7 now claims this bit for close on exit. How about moving all non-standard open flags to the highest possible location, for example #define O_ATOMICLOOKUP 40000000 That way any future official flag extension will not collide with any RHEL specific patches (unless the bits run out).
This is probably a duplicate of bug #358661, but the latter is protected and I can't read it. Jakub Jelinek pointed me to http://people.redhat.com/dzickus/el5/62.el5, and according to the changelog this is fixed since * Thu Dec 20 2007 Don Zickus <dzickus> [2.6.18-62.el5] [...] - [misc] tux: get rid of O_ATOMICLOOKUP (Michal Schmidt ) [358661] [...] So RHEL5.2 seems to have this already fixed, thanks a lot! I'll use the 62 from now on and report back.
*** This bug has been marked as a duplicate of 358661 ***
Please don't close public bugs as duplicate of private ones: > You are not authorized to access bug #358661. To see this bug, > you must first log in to an account with the appropriate permissions. > > Access to some bugs is restricted due to embargoed security issues or respect > for customer and partner information which must remain confidential.
But bug 358661 has been closed, the fix for this issue has been checked into RHEL5.2. Please update to that update release. Can I close this one as CLOSE CURRENTRELEASE?
Yes, thanks for the info, it doesn't need to be more than that.
Per comment#6. Close the bug as CURRENTRELEASE. Thanks.