Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 4892

Summary:	dup2(1, OPEN_MAX) return is not POSIX.1 conformant
Product:	[Retired] Red Hat Linux	Reporter:	Jay Turner <jturner>
Component:	kernel	Assignee:	Michael K. Johnson <johnsonm>
Status:	CLOSED NOTABUG	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	6.0	CC:	alan, srevivo
Target Milestone:	---
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2000-04-22 06:09:02 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 Glen Foster 1999-09-03 19:10:52 UTC

According to POSIX.1 (page 149, 6.2.1.4, lines 70-74), a
call to dup2(1, sysconf(_SC_OPEN_MAX)) should set errno to
EBADF, but instead (incorrectly) sets errno == EMFILE.

This is seen running the PCTS on a stock 6.0 Intel system.

Comment 1 Cristian Gafton 2000-01-04 22:25:59 UTC

Assigned to dledford

Comment 2 Cristian Gafton 2000-01-04 22:26:59 UTC

Assigned to dledford

Comment 3 Bill Nottingham 2000-02-05 23:31:59 UTC

Still exists in 2.2.15pre5.

Comment 4 Doug Ledford 2000-04-22 06:09:59 UTC

Last I knew, this is a backwards compatibility issue.  In order to keep older
binaries from breaking on new kernels that support thousands of open files in a
single application, the kernels have to *pretend* like OPEN_MAX is 1024, like it
used to be.  However, to those applications that know about it, they can call
setrlimit() to increase the number of files allowed.  As far as I know, the
result of this situation is that we have some differing error returns and this
is by design.  If that's wrong, then I'm sure Alan can correct it ;-)