httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Rumph <>
Subject Re: Configuration error handling after httpd restart
Date Mon, 14 Apr 2014 15:15:34 GMT
Hello Jim,

Thanks for taking a look at this and providing a patch for case 2 
(duplicate Listen directives).
I will need to evaluate this patch in more detail.
Your approach of simply ignoring duplicate Listen directives with a 
warning seems reasonable.
At least in the simple case that I listed.
But it does cause a change in behavior for "apachectl -k start" as well 
as "apachectl -k restart".
Is this acceptable?
The same approach could be taken for case 1.
If there is an unknown directive in the config file, simply ignore it 
with a warning.
Does anyone else have an opinion on this?

There are also underlying issues that are bypassed by your fix.
Other more complicated test cases may uncover these again.
I hope to have some time to investigate these issues and do further 
negative testing.



On 4/11/2014 10:43 AM, Jim Riggs wrote:
> On 27 Mar 2014, at 14:16, Mike Rumph <> wrote:
>> Hello all,
>> I have been doing some testing on the results of httpd restart with configuration
>> This gave me some interesting results.
>> For these tests I build httpd trunk with APR trunk on Linux using the following configure:
>> $ ./configure --prefix=/home/mrumph/apache25 --with-included-apr --with-mpm=worker
>> Modify the default httpd.conf to include the following line:
>> Listen localhost:8080
>> Start the httpd server and verify the process information.
>> $ bin/apachectl -k start
>> $ ps -ef | grep -i httpd
>> Now restart httpd from this starting point with the following configuration error
>> Case 1:  An unknown directive.
>> Add the following line to the httpd.conf file.
>> Xyzzy
>> bin/apachectl -k restart
>>    - Returns with exit code 1 and following error message in stderr:
>> AH00526: Syntax error on line 198 of /home/mrumph/apache25/conf/httpd.conf:
>> Invalid command 'Xyzzy', perhaps misspelled or defined by a module not included in
the server configuration
>> httpd: abnormal exit 1
>> $ ps -ef | grep -i httpd
>>    - The httpd server was not stopped and all of the previous processes remain.
>>    - And the logs/ file remains intact.
>> $ tail logs/error_log
>>    - No error message logged.
>> Case 2:  A duplicate Listen directive.
>> Duplicate the Listen directive in the httpd.conf file.
>> Listen localhost:8080
>> Listen localhost:8080
>> $ bin/apachectl -k restart
>>    - Returns with exit code 0 and no error message in stderr.
>>    - So the httpd server appears to be working at this point.
>>    - (But appearances are deceiving.)
>> $ ps -ef | grep -i httpd
>>    - All of the httpd processes have stopped.
>>    - But the logs/ file remains intact.
>> $ tail logs/error_log
>> [Thu Mar 27 11:26:22.836887 2014] [mpm_worker:notice] [pid 2677:tid 47577479346656]
AH00298: SIGHUP received.  Attempting to restart
>> (98)Address already in use: AH00072: make_sock: could not bind to address
>> [Thu Mar 27 11:26:22.844003 2014] [mpm_worker:alert] [pid 2677:tid 47577479346656]
no listening sockets available, shutting down
>> [Thu Mar 27 11:26:22.844031 2014] [core:emerg] [pid 2677:tid 47577479346656] AH00019:
Unable to open logs, exiting
>> This was httpd trunk, but similar results are seen with httpd 2.2.22, 2.2-HEAD and
>> Before working on this as a bug, I am trying to understand what should be the correct
>> I think case 1 is working correctly.
>> But case 2 doesn't seem quite right.
>> First of all, it doesn't seem correct to have an file when all of the httpd
processes have vanished.
>> Secondly, it would be nice to see an error code from the apachectl -k restart.
>> (But this is probably due to a different processing phase in the validation for both
of the cases.)
>> It is also a little strange to see a message "Unable to open logs" in the log.
>> Does anyone have some opinions what the correct behavior should be for these cases.
>> If there are some actual bugs here, I have some time available to work on them.
> Check out the attached patch to ignore duplicate Listen directives.

View raw message