You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@perl.apache.org by Stas Bekman <st...@stason.org> on 2004/11/25 17:15:23 UTC
per-server cleanups core dump? geoff?
Geoff, why there is no thread pointer at this entry?
* per-server cleanups core dump or are otherwise ineffective
Apache->server->process->pconf->cleanup_register(sub { ... });
Report: geoff
could you please give me the info needed to reproduce the problem and I'll
try to fix it? Thanks.
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: per-server cleanups core dump? geoff?
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
> well, I was kind of wondering out loud if we needed to provide per-server
> cleanups like we did in mp1.
>
> the main reason we needed them (as far as I can see) was for performing
> cleanup work when a server was re-started. but we may not need a special
> hook for this in mp2. consider the following (off the top of my head):
>
> my $mtime = -M $httpd.conf;
>
> sub handler {
> ... uses $mtime ...
> }
>
> now, in mp1 $mtime is calculated only on server start for common static
> builds. it is not re-calculated on server restart unless you are using dso
> or PerlFreshRestart. but httpd.conf might be edited between start and
> restart, so you would maintain an accurate mtime with something like
>
> my $mtime = -M $httpd.conf;
> Apache->server->register_cleanup(sub { $mtime = -M $httpd.conf });
>
> that was mp1. but I seem to recall that the interpreter is _always_ broken
> down in mp2, in which case the initial example _will_ reset $mtime on each
> restart via PerlModule. if this is true, then people could use a much
> simpler idiom to perform similar activities, such as initializing caches or
> whatnot.
Right, I'll write a test for that to make sure it really works.
> I'm not saying that we need or should abandon per-server cleanups, since I
> may be missing a use that cannot fit easily into the latter paradigm. but
> if most people have an alternative then it move from showstopper to "nice to
> have."
Right, I'll see if there is a cleaner way to do that with
register_cleanup. If I don't find will move that to nice_to_have list.
Thanks for the commentary, Geoff.
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: per-server cleanups core dump? geoff?
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
>> but now that I'm thinking about it, the interpreter is fully destroyed on
>> restarts, right? that is, a PerlModule will fully load a module both on
>> start _and_ on restart. this wasn't true on static builds in mp1,
>> which is
>> why it was necessary to schedule code callbacks at restart.
>>
>> for instance, a restart callback could clear a cache or update a global
>> httpd.conf mtime. but if PerlModule re-executes module init code on
>> restart
>> then that could be the mechansim. we just couldn't rely on that in
>> mp1 so
>> we had to use a per-server cleanup.
>
>
> You mean we don't need to do anything special? Or what do you exactly
> suggest that we provide?
well, I was kind of wondering out loud if we needed to provide per-server
cleanups like we did in mp1.
the main reason we needed them (as far as I can see) was for performing
cleanup work when a server was re-started. but we may not need a special
hook for this in mp2. consider the following (off the top of my head):
my $mtime = -M $httpd.conf;
sub handler {
... uses $mtime ...
}
now, in mp1 $mtime is calculated only on server start for common static
builds. it is not re-calculated on server restart unless you are using dso
or PerlFreshRestart. but httpd.conf might be edited between start and
restart, so you would maintain an accurate mtime with something like
my $mtime = -M $httpd.conf;
Apache->server->register_cleanup(sub { $mtime = -M $httpd.conf });
that was mp1. but I seem to recall that the interpreter is _always_ broken
down in mp2, in which case the initial example _will_ reset $mtime on each
restart via PerlModule. if this is true, then people could use a much
simpler idiom to perform similar activities, such as initializing caches or
whatnot.
I'm not saying that we need or should abandon per-server cleanups, since I
may be missing a use that cannot fit easily into the latter paradigm. but
if most people have an alternative then it move from showstopper to "nice to
have."
HTH
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: per-server cleanups core dump? geoff?
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
>>So your goal is to be able to register some callback to run when the
>>server restarts and not on every child_exit call.
>
>
> yup. at least if we want to offer the same functionality that mp1 offered.
we also will probably need to implement that pool hack to give the tools
to deal with Starting/Restarting.
> but now that I'm thinking about it, the interpreter is fully destroyed on
> restarts, right? that is, a PerlModule will fully load a module both on
> start _and_ on restart. this wasn't true on static builds in mp1, which is
> why it was necessary to schedule code callbacks at restart.
>
> for instance, a restart callback could clear a cache or update a global
> httpd.conf mtime. but if PerlModule re-executes module init code on restart
> then that could be the mechansim. we just couldn't rely on that in mp1 so
> we had to use a per-server cleanup.
You mean we don't need to do anything special? Or what do you exactly
suggest that we provide?
>>I'll handle that, I just want to understand what exactly I need to solve
>>and get your feedback on it while I move on with it.
>
>
> sure. and thanks for doing all that you are. you make the world a better
> place :)
thanks :)
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: per-server cleanups core dump? geoff?
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> So your goal is to be able to register some callback to run when the
> server restarts and not on every child_exit call.
yup. at least if we want to offer the same functionality that mp1 offered.
but now that I'm thinking about it, the interpreter is fully destroyed on
restarts, right? that is, a PerlModule will fully load a module both on
start _and_ on restart. this wasn't true on static builds in mp1, which is
why it was necessary to schedule code callbacks at restart.
for instance, a restart callback could clear a cache or update a global
httpd.conf mtime. but if PerlModule re-executes module init code on restart
then that could be the mechansim. we just couldn't rely on that in mp1 so
we had to use a per-server cleanup.
>
> In case we don't find a good solution would it be a sufficient
> workaround to run a normal child_exit, but the code will skip all runs
> but the ones whose $$ is of the parent process? (not sure if the parent
> process actually runs child_exit, I think it doesn't).
I dunno.
> Sorry to hear that :(
me too.
>
> I'll handle that, I just want to understand what exactly I need to solve
> and get your feedback on it while I move on with it.
sure. and thanks for doing all that you are. you make the world a better
place :)
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: per-server cleanups core dump? geoff?
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
[...]
>>So may be your orig patch from:
>>http://thread.gmane.org/gmane.comp.apache.mod-perl.devel/730
>>is the way to go,
>
>
> well, if you mean the patch that started the thread, I seem to say there
> that the patch keeps things from segfaulting, but that the callback isn't
> actually run. in other words, the patch didn't really work, but was
> probably meant to be a starting point to something better.
Understood.
So your goal is to be able to register some callback to run when the
server restarts and not on every child_exit call.
In case we don't find a good solution would it be a sufficient workaround
to run a normal child_exit, but the code will skip all runs but the ones
whose $$ is of the parent process? (not sure if the parent process
actually runs child_exit, I think it doesn't).
>>Let me know if you want me to handle that, so we don't put it on the
>>high shelf again.
>
>
> TM has me fully occupied, a situation which isn't likely to change anytime
> soon, so my ability to spend the days it would take to track this down are
> non-existent.
>
> *sigh*
Sorry to hear that :(
I'll handle that, I just want to understand what exactly I need to solve
and get your feedback on it while I move on with it.
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: per-server cleanups core dump? geoff?
Posted by Stas Bekman <st...@stason.org>.
>>But it works perfectly fine for parent process cleanup,
>>but you need to register that in the parent process (i.e. at the server
>>startup). See the modperl_extra.pl addition in the patch below. it logs
>>the date twice on server start, i.e. every time server_pool is recreated.
>
> I swear that it my patch didn't behave this way, but I just tried it and
> placing the cleanup at the module level and using PerlModule work just fine.
Great.
> so +1 on the patch, and sorry it took so long for me to get around to
> testing it.
OK, but it's going to be: Apache::ServerUtil::base_server_pool, so people
don't try to confuse it with a random vhost pool. (also moved from
ServerRec package, since it doesn't belong there, IMHO).
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: per-server cleanups core dump? geoff?
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> Actually your patch, Geoff, was perfectly fine. It wasn't supposed to
> work for cleanups registered from the child processes, because child
> processes don't run cleanup handlers, because server_pool is cleaned
> internally w/o letting the parent pool destroy it (child_exit is a
> special case).
ok
> But it works perfectly fine for parent process cleanup,
> but you need to register that in the parent process (i.e. at the server
> startup). See the modperl_extra.pl addition in the patch below. it logs
> the date twice on server start, i.e. every time server_pool is recreated.
I swear that it my patch didn't behave this way, but I just tried it and
placing the cleanup at the module level and using PerlModule work just fine.
so +1 on the patch, and sorry it took so long for me to get around to
testing it.
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: per-server cleanups core dump? geoff?
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
>>So may be your orig patch from:
>>http://thread.gmane.org/gmane.comp.apache.mod-perl.devel/730
>>is the way to go,
>
>
> well, if you mean the patch that started the thread, I seem to say there
> that the patch keeps things from segfaulting, but that the callback isn't
> actually run. in other words, the patch didn't really work, but was
> probably meant to be a starting point to something better.
Actually your patch, Geoff, was perfectly fine. It wasn't supposed to work
for cleanups registered from the child processes, because child processes
don't run cleanup handlers, because server_pool is cleaned internally w/o
letting the parent pool destroy it (child_exit is a special case). But it
works perfectly fine for parent process cleanup, but you need to register
that in the parent process (i.e. at the server startup). See the
modperl_extra.pl addition in the patch below. it logs the date twice on
server start, i.e. every time server_pool is recreated.
So let me know where are we on this story.
Index: xs/maps/modperl_functions.map
===================================================================
--- xs/maps/modperl_functions.map (revision 109257)
+++ xs/maps/modperl_functions.map (working copy)
@@ -78,6 +78,7 @@
MODULE=Apache::ServerUtil PACKAGE=Apache::ServerRec
SV *:DEFINE_dir_config | | server_rec *:s, char *:key=NULL, SV
*:sv_val=Nullsv
+ apr_pool_t:DEFINE_pool
MODULE=Apache::ServerUtil PACKAGE=Apache::ServerUtil
mpxs_Apache__ServerUtil_server_root_relative | | p, fname=""
Index: xs/Apache/ServerUtil/Apache__ServerUtil.h
===================================================================
--- xs/Apache/ServerUtil/Apache__ServerUtil.h (revision 109257)
+++ xs/Apache/ServerUtil/Apache__ServerUtil.h (working copy)
@@ -13,6 +13,8 @@
* limitations under the License.
*/
+#define mpxs_Apache__ServerRec_pool modperl_server_pool
+
#define mpxs_Apache__ServerRec_method_register(s, methname) \
ap_method_register(s->process->pconf, methname);
Index: t/conf/modperl_extra.pl
===================================================================
--- t/conf/modperl_extra.pl (revision 109257)
+++ t/conf/modperl_extra.pl (working copy)
@@ -49,8 +49,14 @@
test_perl_ithreads();
+my $server_pool = Apache::ServerRec::pool();
+$server_pool->cleanup_register(
+ sub {
+ local %ENV;
+ qx[/bin/date >> /tmp/date];
+ Apache::OK;
+ });
-
### only subs below this line ###
sub reorg_INC {
Index: t/response/TestAPI/server_util.pm
===================================================================
--- t/response/TestAPI/server_util.pm (revision 109257)
+++ t/response/TestAPI/server_util.pm (working copy)
@@ -29,7 +29,7 @@
sub handler {
my $r = shift;
- plan $r, tests => 15;
+ plan $r, tests => 17;
{
my $s = $r->server;
@@ -48,6 +48,14 @@
server_root_relative_tests($r);
+ my $server_pool = Apache::ServerRec::pool();
+ ok $server_pool->isa('APR::Pool');
+
+ # this will never run since it's not registered in the parent
+ # process
+ $server_pool->cleanup_register(sub { Apache::OK });
+ ok 1;
+
Apache::OK;
}
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: per-server cleanups core dump? geoff?
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
>>So may be your orig patch from:
>>http://thread.gmane.org/gmane.comp.apache.mod-perl.devel/730
>>is the way to go,
>
>
> well, if you mean the patch that started the thread, I seem to say there
> that the patch keeps things from segfaulting, but that the callback isn't
> actually run. in other words, the patch didn't really work, but was
> probably meant to be a starting point to something better.
I've added some tracing and it seems that the callbacks aren't run because
the server_pool (a child pool of pconf) is not being cleared at all. In
fact I can see that modperl_sys_term() is not being run at all and I
suppose that it should. I won't be surprised if that would explain some
mysterious problems we had had before.
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: per-server cleanups core dump? geoff?
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> Yes, but I think when it's destroyed perl is long gone, hence the
> segfault.
:)
> child_exit gives the registered callbacks the pchild pool and
> I suppose this is no what you were after in first place (since you
> wanted something to be run only one on server restart).
right.
>
> So may be your orig patch from:
> http://thread.gmane.org/gmane.comp.apache.mod-perl.devel/730
> is the way to go,
well, if you mean the patch that started the thread, I seem to say there
that the patch keeps things from segfaulting, but that the callback isn't
actually run. in other words, the patch didn't really work, but was
probably meant to be a starting point to something better.
> Let me know if you want me to handle that, so we don't put it on the
> high shelf again.
TM has me fully occupied, a situation which isn't likely to change anytime
soon, so my ability to spend the days it would take to track this down are
non-existent.
*sigh*
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: per-server cleanups core dump? geoff?
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
>
> Stas Bekman wrote:
>
>>Geoff, why there is no thread pointer at this entry?
>>
>>* per-server cleanups core dump or are otherwise ineffective
>> Apache->server->process->pconf->cleanup_register(sub { ... });
>> Report: geoff
>>
>>could you please give me the info needed to reproduce the problem and
>>I'll try to fix it? Thanks.
>
>
> see the attached file, which exercises
>
> Apache->server->process->pconf->cleanup_register(sub { ... });
>
> when I try to start the server I get a core dump:
>
> #0 0x001e5744 in ?? ()
> #1 0x00aff901 in run_cleanups (cref=0x92b10b8) at apr_pools.c:1951
> #2 0x00afedb0 in apr_pool_clear (pool=0x92b10a8) at apr_pools.c:693
> #3 0x08070cf6 in main (argc=9, argv=0xbfebcbe4) at main.c:574
>
> from my read of the situation, pconf is the proper pool to use here, since
> it gets destroyed whenever httpd.conf is reparsed (eg restarts), which is
> typically when you need to do per-server cleanups.
Yes, but I think when it's destroyed perl is long gone, hence the
segfault. child_exit gives the registered callbacks the pchild pool and I
suppose this is no what you were after in first place (since you wanted
something to be run only one on server restart).
So may be your orig patch from:
http://thread.gmane.org/gmane.comp.apache.mod-perl.devel/730
is the way to go, but we should make it really clear that the returned
pool is nothing but the main server pool (not vhost). And there is no need
for making it a method, since it's just a function retrieving a global.
So may be it should be called: Apache::Server::global_pool?
Let me know if you want me to handle that, so we don't put it on the high
shelf again.
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: per-server cleanups core dump? geoff?
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
Stas Bekman wrote:
> Geoff, why there is no thread pointer at this entry?
>
> * per-server cleanups core dump or are otherwise ineffective
> Apache->server->process->pconf->cleanup_register(sub { ... });
> Report: geoff
>
> could you please give me the info needed to reproduce the problem and
> I'll try to fix it? Thanks.
see the attached file, which exercises
Apache->server->process->pconf->cleanup_register(sub { ... });
when I try to start the server I get a core dump:
#0 0x001e5744 in ?? ()
#1 0x00aff901 in run_cleanups (cref=0x92b10b8) at apr_pools.c:1951
#2 0x00afedb0 in apr_pool_clear (pool=0x92b10a8) at apr_pools.c:693
#3 0x08070cf6 in main (argc=9, argv=0xbfebcbe4) at main.c:574
from my read of the situation, pconf is the proper pool to use here, since
it gets destroyed whenever httpd.conf is reparsed (eg restarts), which is
typically when you need to do per-server cleanups.
--Geoff