You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Jim Riggs <ap...@riggs.me> on 2014/04/11 19:43:39 UTC
Re: Configuration error handling after httpd restart
On 27 Mar 2014, at 14:16, Mike Rumph <mi...@oracle.com> wrote:
> Hello all,
>
> I have been doing some testing on the results of httpd restart with configuration errors.
> 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 --enable-mpms-shared='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 cases:
>
> 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/httpd.pid 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/httpd.pid 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 127.0.0.1:8080
> [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 2.4.6.
>
>
> Before working on this as a bug, I am trying to understand what should be the correct behavior.
> 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 httpd.pid 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.
Re: Configuration error handling after httpd restart
Posted by Yehuda Katz <ye...@ymkatz.net>.
Since this is up for discussion anyway, what if there was an option to set
a directive as ignore-able.
For example, PHP allows you to preface a function with `@` to ignore errors
(http://www.php.net/manual/en/language.operators.errorcontrol.php).
That way, if you restart and the error is "Invalid command 'Xyzzy',", you
could make the decision to ignore it.
I am not sure how useful this would be in practice. The only thing that
comes to mind is with a module like mod_auth_mysql where you could ignore
errors about it being missing while still requiring some other type of
authentication with satisfy any.
- Y
On Mon, Apr 14, 2014 at 12:00 PM, Jim Riggs <ap...@riggs.me> wrote:
> On 14 Apr 2014, at 10:38, Eric Covener <co...@gmail.com> wrote:
>
> > On Mon, Apr 14, 2014 at 11:15 AM, Mike Rumph <mi...@oracle.com>
> wrote:
> >> If there is an unknown directive in the config file, simply ignore it
> with a
> >> warning.
> >
> > You can't do that. What if it was "Reqiure"?
>
> I agree with Eric. I would not want unknown directives to be ignored. It
> might be a typo of a really important directive like Eric describes. Or,
> what if a module I really, really need is accidentally disabled and we just
> ignore all of its directives? Not good.
>
> In this particular case, duplicating a Listen directive doesn't seem like
> it should bomb out the server.
>
> Listen 80
> ...
> Listen 80
>
> It's superfluous, but not really a critical error. So, my patch just
> ignores subsequent duplicate Listens.
>
>
Re: Configuration error handling after httpd restart
Posted by Jim Riggs <ap...@riggs.me>.
On 14 Apr 2014, at 10:38, Eric Covener <co...@gmail.com> wrote:
> On Mon, Apr 14, 2014 at 11:15 AM, Mike Rumph <mi...@oracle.com> wrote:
>> If there is an unknown directive in the config file, simply ignore it with a
>> warning.
>
> You can't do that. What if it was "Reqiure"?
I agree with Eric. I would not want unknown directives to be ignored. It might be a typo of a really important directive like Eric describes. Or, what if a module I really, really need is accidentally disabled and we just ignore all of its directives? Not good.
In this particular case, duplicating a Listen directive doesn't seem like it should bomb out the server.
Listen 80
...
Listen 80
It's superfluous, but not really a critical error. So, my patch just ignores subsequent duplicate Listens.
Re: Configuration error handling after httpd restart
Posted by Eric Covener <co...@gmail.com>.
On Mon, Apr 14, 2014 at 11:15 AM, Mike Rumph <mi...@oracle.com> wrote:
> If there is an unknown directive in the config file, simply ignore it with a
> warning.
You can't do that. What if it was "Reqiure"?
Re: Configuration error handling after httpd restart
Posted by Mike Rumph <mi...@oracle.com>.
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.
Thanks,
Mike
On 4/11/2014 10:43 AM, Jim Riggs wrote:
> On 27 Mar 2014, at 14:16, Mike Rumph <mi...@oracle.com> wrote:
>
>> Hello all,
>>
>> I have been doing some testing on the results of httpd restart with configuration errors.
>> 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 --enable-mpms-shared='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 cases:
>>
>> 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/httpd.pid 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/httpd.pid 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 127.0.0.1:8080
>> [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 2.4.6.
>>
>>
>> Before working on this as a bug, I am trying to understand what should be the correct behavior.
>> 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 httpd.pid 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.
>
>
>
>