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] New: APR shouldn't rely on build-time results to decide whether to use CLOEXEC or not
Date Fri, 07 Aug 2009 13:47:51 GMT

           Summary: APR shouldn't rely on build-time results to decide
                    whether to use CLOEXEC or not
           Product: APR
           Version: HEAD
          Platform: All
        OS/Version: Linux
            Status: NEW
          Severity: major
          Priority: P2
         Component: APR
        AssignedTo: bugs@apr.apache.org
        ReportedBy: flameeyes@gentoo.org

--- Comment #0 from Diego Petten <flameeyes@gentoo.org> 2009-08-07 06:47:46 PDT ---
I hit a very nasty bump on the update road today on my Gentoo server, when
updating apr to the latest version (1.3.8). The issue starts showing up with

vanguard ~ # /etc/init.d/apache2 restart
 * apache2 has detected a syntax error in your configuration files:
[Fri Aug 07 11:39:07 2009] [crit] (22)Invalid argument: alloc_listener: failed
to get a socket for
Syntax error on line 1 of /etc/apache2/vhosts.d/00_default_vhost.conf:
Listen setup failed
 * ERROR: apache2 failed to start

The line in question is a standard “Listen 80” that works with the previous
version. After some lucky digging around, the actual problem is that the
autoconf script checks for CLOEXEC support by _running_ test code at
build-time, but this discovers the availability of CLOEXEC on the _build_
system; it's not uncommon to use different build and host systems, and they
might differ in kernel, which is my case (it's true for binary distributions as
well that use build servers).

There is one further problem: if I do use apr_cv_sock_cloexec=no to fool the
configure script into not finding the cloexec support, Apache starts up, open
the socket, but the children segfault; the problem is that the code checks, in
mostly the same way, for the epoll_create1() function, _even if cloexec wasn't
found_, and the impossible combination creates the segfault. Setting
apr_cv_epoll_create1=no fools configure again and it starts to work.

I don't think that this is the right approach sincerely, since beside this
particular case of having the host system running on an older kernel, the
opposite is also bad; if the build system has an old kernel running, but a new
enough glibc, it'll be disabling cloexec, that the host system would have been
able to use.

I haven't looked at the code enough yet (and I'm afraid I won't have way to do
that till the 20th, but my proposal would be to do something like this:

 1) in autoconf check for the declaration of flag and function, not their
working order;
 2) write the codepaths, rather than using #ifdef, with standard if() clauses,
for either cloexec or no-cloexec; make the if condition a macro like
 3) add an option to the configure script to either force off or on the cloexec
support, or let it be automatically used;
 4) if the support is forced on or off, declare APR_USE_CLOEXEC a constant, set
to 1 or 0;
 5) if the support is auto, but the declarations weren't found, also declare
APR_USE_CLOEXEC a constant 0;
 6) if the support is auto, and the declaration were found, make
APR_USE_CLOEXEC a macro to function; this function would be something like:

int apr_use_cloexec_check() {
  static int apr_use_cloexec = -1;
  if ( apr_use_cloexec == -1 ) {
    [... run some quick runtime test for cloexec to work ...]
  return apr_use_cloexec;

(this will cache the result so that the test is executed at most once)

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