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
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?
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
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
[Fixing assignment - please don't change the bug assignment, all bugs need to remain assigned to the mailing list address.]
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?
Created attachment 18841 [details] patch APR resolver bug on Tru64
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.
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.