This is somewhat related to bug 34148, but addresses a different point: Apache's elected handling of Listen statements violates the principle of least surprise, as well as making it very hard to detect when something might not work. Here are three examples, the third is what I think is wrong. The examples have been tested with Apache 2.2.6 (Debian squeeze) and 2.2.22 (Debian wheezy). ---------------------------------------------------------------------- 1) Bogus IP address (e.g. 999999.99999.9999) ---------------------------------------------------------------------- root@server:~# apachectl configtest Syntax error on line 17 of /etc/apache2/ports.conf: Port must be specified Action 'configtest' failed. The Apache error log may have more information. root@server:~# echo $? 1 ---------------------------------------------------------------------- 2) Valid, unconfigured IP address, port unspecified (e.g. 10.0.0.2): ---------------------------------------------------------------------- root@server:~# apachectl configtest Syntax error on line 17 of /etc/apache2/ports.conf: Port must be specified Action 'configtest' failed. The Apache error log may have more information. root@server:~# echo $? 1 ---------------------------------------------------------------------- 3) Valid, unconfigured IP address, port specified (e.g. 10.0.0.2:80): ---------------------------------------------------------------------- root@server:~# apachectl configtest Syntax OK root@server:~# echo $? 0 root@server:~# service apache2 reload Reloading web server config: apache2. root@server:~# lsof -Pni:80 root@server:~# pgrep apache2 root@server:~# tail -4 /var/log/apache2/error_log [Thu Aug 01 15:29:48 2013] [notice] SIGUSR1 received. Doing graceful restart (99)Cannot assign requested address: make_sock: could not bind to address 10.0.0.2:80 no listening sockets available, shutting down Unable to open logs ---------------------------------------------------------------------- There are two sane ways of handling this, and I think both should be implemented, as they complement eachother: a) Do NOT pass config testing when a listening socket is unavailable. Consider having different return codes depending on how many listening sockets fail: I) no II) some III) all b) Do not say "no listening sockets available" and do not shut down, when there are several listening sockets available, which are both valid and configured, and ready to use. Merely ignore those that cannot be opened, and if _absolutely no_ sockets can be opened, shut down.
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.