apr-bugs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 47662] APR shouldn't rely on build-time results to decide whether to use CLOEXEC or not
Date Fri, 14 Aug 2009 08:00:43 GMT

Joe Orton <jorton@redhat.com> changed:

           What    |Removed                     |Added
             Status|REOPENED                    |RESOLVED
         Resolution|                            |INVALID

--- Comment #5 from Joe Orton <jorton@redhat.com> 2009-08-14 01:00:37 PDT ---
(In reply to comment #4)
> "Apache starts up, open the socket, but the children segfault; " - this one
> should be addressed. Some error should be logged instead of segfaulting.

I'm not sure exactly what causes that but would probably agree; if someone who
can reproduce that could file a separate bug against httpd that would be great.

(In reply to comment #3)
> Distributions very often update kernel-headers much more often than the kernel
> itself.

That is not the issue.  APR does not rely on mere presence of the interfaces,
but tests them and ensures that they work.

This is little different, in principle, to any of the hundreds of other
platform features which APR detects at build-time, and subsequently assumes are
present at run-time.

> Besides, this would make it impossible for distributions to provide an
> updated APR without disabling SOCK_CLOEXEC, patching it, or enabling the
> installation only on machines running a new-enough kernel (or forcing a reboot
> if the kernel is not old enough).

This is not correct either - as Bojan says in comment 2 it is simple enough for
those producing binary distributions to disable these features at build time. 
It is not at all unreasonable to expect distributors to have to manage this
mismatch between "platform features as detected at build-time by configure" and
"platform features available on minimal target run-time".

This thread is the discussion on the list previously:


Please take further discussion to the list and refrain from playing ping-pong
with the bug status.  The impact of this decision is well understood and is not
being treated as a bug.

Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

To unsubscribe, e-mail: bugs-unsubscribe@apr.apache.org
For additional commands, e-mail: bugs-help@apr.apache.org

View raw message