Bug 40408 - Apache 2.2.3 is not starting
Summary: Apache 2.2.3 is not starting
Status: RESOLVED LATER
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: All (show other bugs)
Version: 2.2.2
Hardware: DEC OSF/1
: P1 blocker with 1 vote (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
URL:
Keywords: MassUpdate
Depends on:
Blocks:
 
Reported: 2006-09-04 10:53 UTC by Laxmi harikumar
Modified: 2018-11-07 21:08 UTC (History)
2 users (show)



Attachments
patch APR resolver bug on Tru64 (628 bytes, patch)
2006-09-08 09:28 UTC, Joe Orton
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Laxmi harikumar 2006-09-04 10:53:57 UTC
We downloaded the source tar (httpd-2.2.3.tar.gz) and ran configure, make and
make install.

While trying to start apache by "apachectl -k start", Apache 2.2.3 does not give
any error messages while starting but it is not actually starting. We could not
find any clues in error_log as well (It is just 0 bytes).

We tried starting "httpd" with debugger (ladebug). In server/main.c, line 686,
it just comes out after 

if (ap_run_pre_config(pconf, plog, ptemp) != OK) {
    ap_log_error(APLOG_MARK, APLOG_STARTUP |APLOG_ERR,
                  0, NULL, "Pre-configuration failed");
              destroy_and_exit_process(process, 1);
         }

It doesn't go inside the if condition (ap_log_error part). By stepping inside
the function ap_run_pre_config, it goes inside
./srclib/apr/threadproc/unix/procsup.c and comes out of the exit 0 line of
  if (daemonize) {
            if ((x = fork()) > 0) {
                exit(0);
        }

Should we try any more options?

Thanks
Laxmi
Comment 1 Joe Orton 2006-09-04 11:07:16 UTC
Can you try starting up in single-process mode by passing the -X argument?  If
this fails silently can you run it under some ktrace-like tool to get a system
call trace?
Comment 2 Laxmi harikumar 2006-09-04 11:35:08 UTC
Hi Joe,

I tried starting with "httpd -X -k start". Apache 2 is configured to run on port
81. This is the error in error_log file now:

(48)Address already in use: make_sock: could not bind to address 0.0.0.0:81
no listening sockets available, shutting down
Unable to open logs

I tried changing the port to 83. Still the same error:
(48)Address already in use: make_sock: could not bind to address 0.0.0.0:83
no listening sockets available, shutting down
Unable to open logs

Thanks,
Laxmi
Comment 3 Laxmi harikumar 2006-09-08 09:04:57 UTC
This problem is Tru64 specific. Here the make_sock function is being called
twice with IP address 0.0.0.0 and the second bind obviously fails.

In alloc_listener function of listen.c, the comparison:

264 if (port == oldport &&
265 ((!addr && !sa->hostname) ||
266                   ((addr && sa->hostname) && !strcmp(sa->hostname, addr))

is failing (when the function gets called the second time) because of which
found_listener is not set to 1 

This is failing because sa->hostname is being set to "0.0.0.0" in
apr_sockaddr_info_get (which in turn calls call_resolver() in sockaddr.c. This
function has a #ifdef OSF1 where hostname is being set as 0.0.0.0 or ::
depending on IPv4 or IPv6).

We have tried a fix on the same issue for alloc_listener(). Posting it here.

File listen.c
------------

34,38c34
< #if APR_HAVE_IPV6
< static int default_family = APR_UNSPEC;
< #else
< static int default_family = APR_INET;
< #endif
---
>
248,272d243
< static void find_default_family(apr_pool_t *p)
< {
< #if APR_HAVE_IPV6
<     if (default_family == APR_UNSPEC) {
<         apr_status_t sock_rv;
<         apr_socket_t *tmp_sock;
<         apr_sockaddr_t *sa;
<
<         if ((sock_rv = apr_socket_create(&tmp_sock, APR_INET6, SOCK_STREAM, 0,
 p))
<             == APR_SUCCESS &&
< apr_sockaddr_info_get(&sa, NULL, APR_INET6, 0, 0, p) == APR_SUCCESS
< &&
<             apr_socket_bind(tmp_sock, sa) == APR_SUCCESS) {
<             default_family = APR_INET6;
<         }
<         else {
<             default_family = APR_INET;
<         }
<         if (sock_rv == APR_SUCCESS) {
<             apr_socket_close(tmp_sock);
<         }
<     }
< #endif
< }
<
280,299d250
<
< #ifdef OSF1
<     if (!addr) { /* don't bind to specific interface */
<         find_default_family(process->pool);
<         switch(default_family) {
<         case APR_INET:
<             addr = "0.0.0.0";
<             break;
<
< #if APR_HAVE_IPV6
<         case APR_INET6:
<             addr = "::";
<             break;
< #endif
<
<         default:
<             ap_assert(1 != 1); /* should not occur */
<         }
<     }
< #endif
Comment 4 Joe Orton 2006-09-08 09:20:22 UTC
[Fixing assignment - please don't change the bug assignment, all bugs need to
remain assigned to the mailing list address.]

Comment 5 Joe Orton 2006-09-08 09:27:46 UTC
The fix for this might be in APR.  Can you revert your changes and try a few
things from the vanilla 2.2.3 code?

1) If you change the configuration to "Listen 0.0.0.0:80" does the server start
up OK?

2) With the default configuration of just "Listen 80", can you try the patch
I'll attach against APR?
Comment 6 Joe Orton 2006-09-08 09:28:21 UTC
Created attachment 18841 [details]
patch APR resolver bug on Tru64
Comment 7 Laxmi harikumar 2006-09-08 11:00:17 UTC
1. With the configuration changed to "Listen 0.0.0.0:80" the server starts.
2. But with the patch and the default configuration of "Listen 80" it doesnt.
Comment 8 William A. Rowe Jr. 2018-11-07 21:08:58 UTC
Please help us to refine our list of open and current defects; this is a mass update of old and inactive Bugzilla reports which reflect user error, already resolved defects, and still-existing defects in httpd.

As repeatedly announced, the Apache HTTP Server Project has discontinued all development and patch review of the 2.2.x series of releases. The final release 2.2.34 was published in July 2017, and no further evaluation of bug reports or security risks will be considered or published for 2.2.x releases. All reports older than 2.4.x have been updated to status RESOLVED/LATER; no further action is expected unless the report still applies to a current version of httpd.

If your report represented a question or confusion about how to use an httpd feature, an unexpected server behavior, problems building or installing httpd, or working with an external component (a third party module, browser etc.) we ask you to start by bringing your question to the User Support and Discussion mailing list, see [https://httpd.apache.org/lists.html#http-users] for details. Include a link to this Bugzilla report for completeness with your question.

If your report was clearly a defect in httpd or a feature request, we ask that you retest using a modern httpd release (2.4.33 or later) released in the past year. If it can be reproduced, please reopen this bug and change the Version field above to the httpd version you have reconfirmed with.

Your help in identifying defects or enhancements still applicable to the current httpd server software release is greatly appreciated.