You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Stefan Fritsch <sf...@sfritsch.de> on 2010/11/12 19:47:29 UTC
API for detecting first config run
Hi,
it is common procedure for modules to detect the first configuration
run at httpd startup by looking for some userdata in the process pool.
If the userdata is not set, they set it and then skip some
initialization that should not be done during the first config run.
But this logic is broken: If a LoadModule statement is added while
httpd is running, and httpd is then gracefully restarted, the module
will be loaded but assume that this is the startup configuration
phase. It won't initialize itself fully and will work correctly only
after the second graceful restart. This can be very confusing for
users.
Therefore I intend to add some API like ap_in_initial_configuration()
which will tell modules reliably if httpd is currently starting up or
not. Does anyone see a problem with this that I have missed?
Cheers,
Stefan
Re: API for detecting first config run
Posted by Stefan Fritsch <sf...@sfritsch.de>.
On Sunday 14 November 2010, Jeff Trawick wrote:
> On Sun, Nov 14, 2010 at 3:51 PM, Stefan Fritsch <sf...@sfritsch.de>
wrote:
> > On Saturday 13 November 2010, Jeff Trawick wrote:
> >> >> which questions should modules be able to ask?
> >> >>
> >> >> last-load/init-before-activation? (seems to work for
> >> >> most purposes)
> >> >
> >> > Yes, that's what I meant: Will the current config be actually
> >> > used to process requests?
> >> >
> >> >> pre-detach-load/init? (never seen when added during
> >> >> restart) (not to mention weird Windows stuff -- is this the
> >> >> parent or the child, and which pass)
> >> >
> >> > Is this something that modules need to be aware of? Usually
> >> > it's just that the module needs to do something
> >> > time-consuming, but only wants to do it for the config that
> >> > is actually used for requests. E.g mod_rewrite will skip
> >> > spawning the rewrite map children during the first config
> >> > run, and mod_php will skip initializing its interpreter. If
> >> > there are modules that need more specific information, the
> >> > new API should probably provide that. But I am not aware of
> >> > any such modules.
> >>
> >> anything that prompts the user for passphrase or wants to issue
> >> a warning message cares about pre-detach
> >>
> >> I'm not sure about awareness of the Windows oddity; my vague
> >> understanding is that a lot of modules perform wasted init in
> >> the Windows parent. If was important to know, how would the
> >> module check?
> >>
> >> >> should pre-config and post-config just get an indicator?
> >> >
> >> > I am not sure what you mean here.
> >>
> >> sorry; "other parameter(s) to those hooks to tell them the
> >> server state" (but modifying the parameter lists is an
> >> aggravating migration step)
> >
> > No, that's too intrusive. Right now I think the following would
> > be best:
> >
> > - Adding new query codes to ap_mpm_query as necessary, starting
> > with AP_MPMQ_STARTUP_STATE_FINAL_CONFIG
> > - Giving the MPM a way to check if we are in the first config run
> > on startup by setting some global variable in main.c, adding a
> > note that normal modules should use ap_mpm_query instead of the
> > variable.
> >
> > This way the MPM can influence what is returned and the interface
> > is extensible.
>
> This particular behavior is not determined or influenced by the
> MPM; it is hard-coded into main()*. In fact, MPM modules may wish
> to use a new API. So ap_mpm_query() shouldn't be used for this.
>
> *perhaps some platform-specific details are elsewhere
I want to come back to this issue. Apart from modules asking the
question "will this config actually be used for processing requests",
I would like to have an answer to "are we only testing the config" and
"are we only dumping some parts of the config".
For example, if we are only dumping some parts of the config, we may
want to skip asking the user for SSL-key passphrases.
So, I propose to add an extensible API analogous to ap_mpm_query, but
for the main process. I would maybe just call it ap_state_query(). For
a start, I would implement two query options:
AP_SQ_MAIN_STATE: This would correspond to which part of main.c is
currently executing:
AP_SQ_STARTING
AP_SQ_CREATE_PRE_CONFIG
AP_SQ_DESTROY_CONFIG
AP_SQ_CREATE_CONFIG
AP_SQ_RUN_MPM
AP_SQ_EXITING
The three states AP_SQ_STATE_DESTROY_CONFIG, ..., AP_SQ_STATE_RUN_MPM
would repeat after every graceful restart.
AP_SQ_RUN_MODE: This would allow to find out if some config dump was
requested (without having to know the names of all DUMP_* defines):
AP_SQ_CONFIG_TEST
AP_SQ_CONFIG_DUMP
AP_SQ_SERVE_REQUESTS
Any comments? Ideas for better names?
Re: API for detecting first config run
Posted by Jeff Trawick <tr...@gmail.com>.
On Sun, Nov 14, 2010 at 3:51 PM, Stefan Fritsch <sf...@sfritsch.de> wrote:
> On Saturday 13 November 2010, Jeff Trawick wrote:
>> >> which questions should modules be able to ask?
>> >>
>> >> last-load/init-before-activation? (seems to work for
>> >> most purposes)
>> >
>> > Yes, that's what I meant: Will the current config be actually
>> > used to process requests?
>> >
>> >> pre-detach-load/init? (never seen when added during restart)
>> >> (not to mention weird Windows stuff -- is this the parent or the
>> >> child, and which pass)
>> >
>> > Is this something that modules need to be aware of? Usually it's
>> > just that the module needs to do something time-consuming, but
>> > only wants to do it for the config that is actually used for
>> > requests. E.g mod_rewrite will skip spawning the rewrite map
>> > children during the first config run, and mod_php will skip
>> > initializing its interpreter. If there are modules that need
>> > more specific information, the new API should probably provide
>> > that. But I am not aware of any such modules.
>>
>> anything that prompts the user for passphrase or wants to issue a
>> warning message cares about pre-detach
>>
>> I'm not sure about awareness of the Windows oddity; my vague
>> understanding is that a lot of modules perform wasted init in the
>> Windows parent. If was important to know, how would the module
>> check?
>>
>> >> should pre-config and post-config just get an indicator?
>> >
>> > I am not sure what you mean here.
>>
>> sorry; "other parameter(s) to those hooks to tell them the server
>> state" (but modifying the parameter lists is an aggravating
>> migration step)
>
> No, that's too intrusive. Right now I think the following would be
> best:
>
> - Adding new query codes to ap_mpm_query as necessary, starting with
> AP_MPMQ_STARTUP_STATE_FINAL_CONFIG
> - Giving the MPM a way to check if we are in the first config run on
> startup by setting some global variable in main.c, adding a note that
> normal modules should use ap_mpm_query instead of the variable.
>
> This way the MPM can influence what is returned and the interface is
> extensible.
This particular behavior is not determined or influenced by the MPM;
it is hard-coded into main()*. In fact, MPM modules may wish to use a
new API. So ap_mpm_query() shouldn't be used for this.
*perhaps some platform-specific details are elsewhere
Re: API for detecting first config run
Posted by Stefan Fritsch <sf...@sfritsch.de>.
On Saturday 13 November 2010, Jeff Trawick wrote:
> >> which questions should modules be able to ask?
> >>
> >> last-load/init-before-activation? (seems to work for
> >> most purposes)
> >
> > Yes, that's what I meant: Will the current config be actually
> > used to process requests?
> >
> >> pre-detach-load/init? (never seen when added during restart)
> >> (not to mention weird Windows stuff -- is this the parent or the
> >> child, and which pass)
> >
> > Is this something that modules need to be aware of? Usually it's
> > just that the module needs to do something time-consuming, but
> > only wants to do it for the config that is actually used for
> > requests. E.g mod_rewrite will skip spawning the rewrite map
> > children during the first config run, and mod_php will skip
> > initializing its interpreter. If there are modules that need
> > more specific information, the new API should probably provide
> > that. But I am not aware of any such modules.
>
> anything that prompts the user for passphrase or wants to issue a
> warning message cares about pre-detach
>
> I'm not sure about awareness of the Windows oddity; my vague
> understanding is that a lot of modules perform wasted init in the
> Windows parent. If was important to know, how would the module
> check?
>
> >> should pre-config and post-config just get an indicator?
> >
> > I am not sure what you mean here.
>
> sorry; "other parameter(s) to those hooks to tell them the server
> state" (but modifying the parameter lists is an aggravating
> migration step)
No, that's too intrusive. Right now I think the following would be
best:
- Adding new query codes to ap_mpm_query as necessary, starting with
AP_MPMQ_STARTUP_STATE_FINAL_CONFIG
- Giving the MPM a way to check if we are in the first config run on
startup by setting some global variable in main.c, adding a note that
normal modules should use ap_mpm_query instead of the variable.
This way the MPM can influence what is returned and the interface is
extensible.
Sounds OK?
Re: API for detecting first config run
Posted by Jeff Trawick <tr...@gmail.com>.
On Fri, Nov 12, 2010 at 4:10 PM, Stefan Fritsch <sf...@sfritsch.de> wrote:
> On Fri, 12 Nov 2010, Jeff Trawick wrote:
>>
>> On Fri, Nov 12, 2010 at 2:59 PM, William A. Rowe Jr.
>> <wr...@rowe-clan.net> wrote:
>>>
>>> On 11/12/2010 12:47 PM, Stefan Fritsch wrote:
>>>>
>>>> it is common procedure for modules to detect the first configuration
>>>> run at httpd startup by looking for some userdata in the process pool.
>>>> If the userdata is not set, they set it and then skip some
>>>> initialization that should not be done during the first config run.
>>>>
>>>> But this logic is broken: If a LoadModule statement is added while
>>>> httpd is running, and httpd is then gracefully restarted, the module
>>>> will be loaded but assume that this is the startup configuration
>>>> phase. It won't initialize itself fully and will work correctly only
>>>> after the second graceful restart. This can be very confusing for
>>>> users.
>>>
>>> That's why you would generally add a pool datum to the process->pool,
>>> which survives module unload/reload.
>>>
>>
>> see also ap_retained_data_{create|get} which hides the pool trick; but
>> Stefan is getting at a specific question that the module wants to ask
>> so that it can potentially work if added across restart
>>
>> which questions should modules be able to ask?
>>
>> last-load/init-before-activation? (seems to work for most
>> purposes)
>
> Yes, that's what I meant: Will the current config be actually used to
> process requests?
>
>> pre-detach-load/init? (never seen when added during restart)
>> (not to mention weird Windows stuff -- is this the parent or the
>> child, and which pass)
>
> Is this something that modules need to be aware of? Usually it's just that
> the module needs to do something time-consuming, but only wants to do it for
> the config that is actually used for requests. E.g mod_rewrite will skip
> spawning the rewrite map children during the first config run, and mod_php
> will skip initializing its interpreter. If there are modules that need more
> specific information, the new API should probably provide that. But I am not
> aware of any such modules.
anything that prompts the user for passphrase or wants to issue a
warning message cares about pre-detach
I'm not sure about awareness of the Windows oddity; my vague
understanding is that a lot of modules perform wasted init in the
Windows parent. If was important to know, how would the module check?
>
>> should pre-config and post-config just get an indicator?
>
> I am not sure what you mean here.
sorry; "other parameter(s) to those hooks to tell them the server
state" (but modifying the parameter lists is an aggravating migration
step)
Re: API for detecting first config run
Posted by Stefan Fritsch <sf...@sfritsch.de>.
On Fri, 12 Nov 2010, Jeff Trawick wrote:
> On Fri, Nov 12, 2010 at 2:59 PM, William A. Rowe Jr.
> <wr...@rowe-clan.net> wrote:
>> On 11/12/2010 12:47 PM, Stefan Fritsch wrote:
>>> it is common procedure for modules to detect the first configuration
>>> run at httpd startup by looking for some userdata in the process pool.
>>> If the userdata is not set, they set it and then skip some
>>> initialization that should not be done during the first config run.
>>>
>>> But this logic is broken: If a LoadModule statement is added while
>>> httpd is running, and httpd is then gracefully restarted, the module
>>> will be loaded but assume that this is the startup configuration
>>> phase. It won't initialize itself fully and will work correctly only
>>> after the second graceful restart. This can be very confusing for
>>> users.
>>
>> That's why you would generally add a pool datum to the process->pool,
>> which survives module unload/reload.
>>
>
> see also ap_retained_data_{create|get} which hides the pool trick; but
> Stefan is getting at a specific question that the module wants to ask
> so that it can potentially work if added across restart
>
> which questions should modules be able to ask?
>
> last-load/init-before-activation? (seems to work for most purposes)
Yes, that's what I meant: Will the current config be actually used to
process requests?
> pre-detach-load/init? (never seen when added during restart)
> (not to mention weird Windows stuff -- is this the parent or the
> child, and which pass)
Is this something that modules need to be aware of? Usually it's just that
the module needs to do something time-consuming, but only wants to do it
for the config that is actually used for requests. E.g mod_rewrite will
skip spawning the rewrite map children during the first config run, and
mod_php will skip initializing its interpreter. If there are modules that
need more specific information, the new API should probably provide that.
But I am not aware of any such modules.
> should pre-config and post-config just get an indicator?
I am not sure what you mean here.
Cheers,
Stefan
Re: API for detecting first config run
Posted by Jeff Trawick <tr...@gmail.com>.
On Fri, Nov 12, 2010 at 2:59 PM, William A. Rowe Jr.
<wr...@rowe-clan.net> wrote:
> On 11/12/2010 12:47 PM, Stefan Fritsch wrote:
>> Hi,
>>
>> it is common procedure for modules to detect the first configuration
>> run at httpd startup by looking for some userdata in the process pool.
>> If the userdata is not set, they set it and then skip some
>> initialization that should not be done during the first config run.
>>
>> But this logic is broken: If a LoadModule statement is added while
>> httpd is running, and httpd is then gracefully restarted, the module
>> will be loaded but assume that this is the startup configuration
>> phase. It won't initialize itself fully and will work correctly only
>> after the second graceful restart. This can be very confusing for
>> users.
>
> That's why you would generally add a pool datum to the process->pool,
> which survives module unload/reload.
>
see also ap_retained_data_{create|get} which hides the pool trick; but
Stefan is getting at a specific question that the module wants to ask
so that it can potentially work if added across restart
which questions should modules be able to ask?
last-load/init-before-activation? (seems to work for most purposes)
pre-detach-load/init? (never seen when added during restart)
(not to mention weird Windows stuff -- is this the parent or the
child, and which pass)
should pre-config and post-config just get an indicator?
Re: API for detecting first config run
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 11/12/2010 12:47 PM, Stefan Fritsch wrote:
> Hi,
>
> it is common procedure for modules to detect the first configuration
> run at httpd startup by looking for some userdata in the process pool.
> If the userdata is not set, they set it and then skip some
> initialization that should not be done during the first config run.
>
> But this logic is broken: If a LoadModule statement is added while
> httpd is running, and httpd is then gracefully restarted, the module
> will be loaded but assume that this is the startup configuration
> phase. It won't initialize itself fully and will work correctly only
> after the second graceful restart. This can be very confusing for
> users.
That's why you would generally add a pool datum to the process->pool,
which survives module unload/reload.