On Fri, Jun 29, 2001 at 02:09:44PM +0300, Zeev Suraski wrote:
> At 18:45 28/6/2001, Thies C. Arntzen wrote:
>
> > hi,
> >
> > we have two problems in the current code when it comes to
> > shutting down apache processes:
> >
> > 1)
> > in main.c php_module_shutdown():
> > we call php_config_ini_shutdown() before we call the modules
> > MSHUTDOWN functions - which basically means that php is
> > already "half-dead" when MSHUTDOWN is called - so modules can
> > can not rely on certain things (like error_log settings)
> > during MSHUDOWN. is there any known reason not to move
> > php_config_ini_shutdown() further down in
> > php_module_shutdown()?
>
> The problem is that (if I remember correctly) the INI mechanism may call
> callbacks in modules that have already been unloaded. It can probably be
> fixed, but would require some time to play with.
agreed - but we should do it, right?
>
>
> > 2) (more serious)
> > if you do an "apachectl restart" the master httpd will signal
> > the worker httpd's. the workers will than call the
> > child_exit hook in all modules no matter where in the code
> > they just happen to be. the problem is that we "try"
> > to clean up the best we can -but- this might cause recursive
> > calls into 3th party library code (which is not supported in
> > most cases!)
> >
> > sample:
> >
> > script calls ociexecute($stmt) (which might take a few
> > seconds) now the admin does "apachectl restart" - and we
> > get interrupted deep down in the oci library. now the worker
> > httpd tries to clean up and calls the child_exit hooks. php
> > will now free all resources and it will also try to do a
> > rollback on $stmt and after that it'll free $stmt. the
> > problem here is that the oracle-server _doesn't_ like
> > recursive calls at all and might crash just 'cause of that.
> >
> > OK - i agree - oracle should fix their code, -but- i don't
> > think its smart to try a real-cleanup if we we're
> > interrunpted during a request. i think we need to protect the
> > engine agains recursive calls. so if child_exit is called
> > while we're still in execution mode simply do nothing
> > (bacause all we could do might be harmful) and leave the
> > clean up to unix.
>
> I don't know if that qualifies as a recursive call - it's really doing what
> it's supposed to do. Perhaps the Oracle module should protect itself, but
> not running cleanup is wrong IMHO - consider semaphores or the likes which
> won't clean up automatically. Or SQL servers that won't immediately detect
> that their client is gone. I think that cleaning up is generally an
> important thing.
i agree - in theory. but "apachectl restart" will sometimes
SEGFAULT some httpd processes because of php. just create a
trivial page that will take some time:
test.php
<?php
for ($i = 0; $i < 1000000; $i++) ;
?>
run "ab -n1000 http://0/test.php";
and then do an apachectl restart (a few times) and you'll see
zend_execute.c(376) : Freeing 0x08162BDC (12 bytes), script=/var/www/html/t.php
zend_hash.c(287) : Freeing 0x08162B84 (37 bytes), script=/var/www/html/t.php Last
leak repeated 160 times
zend_opcode.c(303) : Freeing 0x08161AEC (720 bytes), script=/var/www/html/t.php
zend_language_scanner.c(4153) : Freeing 0x08162B4C (2 bytes),
script=/var/www/html/t.php
zend_opcode.c(237) : Freeing 0x08162B0C (12 bytes), script=/var/www/html/t.php
zend_language_scanner.c(4238) : Freeing 0x08162AD4 (2 bytes),
script=/var/www/html/t.php Last leak repeated 2 times
zend_opcode.c(71) : Freeing 0x08161AB4 (4 bytes), script=/var/www/html/t.php
zend_compile.c(118) : Freeing 0x081619C4 (20 bytes),
...
in the error_log - and sometimes it'll even SEGFAULT.
is this good?
tc
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
