Re: slotmem improving doall
On 09/30/2009 06:18 PM, Jim Jagielski wrote: On Sep 29, 2009, at 5:23 AM, jean-frederic clere wrote: Hi, I would like to change the doall / ap_slotmem_callback_fn_t logic. For the moment we can't stop the doall loop, but it could be interesting to do so (for example while search for a value in the slotmems). My idea is to return APR_SUCCESS when done and APR_INCOMPLETE if we want to go on doing the loop. How would it be re-entrant? hmmm... Well the caller would have to solve that problem, it is a loop calling a callback, no? Cheers Jean-Frederic
Re: mod_serf uses non-public API
On 10/01/2009 03:45 AM, Guenter Knauf wrote: Paul, Paul Querna schrieb: very likely, mod_serf in its current for should just be polished to replace mod_proxy_*, and all of the async stuff should be pushed towards the MPMs.. well the question is: do we want to export ap_process_request_after_handler() in the future, and if so we should AP_DECLARE it; Well as Paul commented it is just a quick hack to get mod_serf running +0 Cheers Jean-Frederic I've just found that test/mod_dial_up.c uses this function too in line 119 ... Gün.
Re: mod_fcgid - cannot get authorizer process to be started
Jeff Trawick wrote: On Wed, Sep 30, 2009 at 11:37 AM, Barry Scott barry.sc...@onelan.co.uk mailto:barry.sc...@onelan.co.uk wrote: At this point let me ask this: Is it possible with the current code to ever have the fcgid Authorizer called? yes thanks for the confirmation and the example. I now have my Authorizer code and have the authentication happening. Listen *:9000 VirtualHost *:9000 Location / Order allow,deny Allow from all AuthType Digest AuthName Manager System AuthUserFile /home/bscott/Work/httpd-fcgid-test/auth/http.passwd Require onelan magic FastCgiAuthorizer /home/bscott/wc/svn/NTB-Next/onelan/DSM/Sources/WebUserInterface/bin/Authorizer.sh /Location /VirtualHost What I have learned about the code is this: * If any Require directive is present a 401 is returned if no credentials are sent * If any Require directive is present and credentials are present they are checked and the username is set in r. * If any Require directive is present and its not processed by any other authorizer the FastCgiAuthorizer is run It would be nice to reserve a Require entity name for use by fast CGI. The code as written today does not care if a Require entity name is processed by any module. Use of valid-group that sound officialbut is simply a Require entity name that no module supports. Barry
Re: [vote] release httpd-2.2.14?
Guenter Knauf wrote: still not sync'd, also my NetWare binaries not; there is something wrong ... Two emails to infrastructure@ have gone ignored, does anyone know what is going on? Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
[Fwd: SvnPubSub websites -- need more volunteers]
Hi all, Does httpd want to volunteer for this? Regards, Graham -- ---BeginMessage--- Hi, apr.apache.org is now managed by SvnPubSub. I think we are ready to add more. Any volunteer TLPs? Once its done, any commit to your SVN repo for your site will be automatically propagated to the live servers within seconds. Things i need to know: - Path to Website Checkout - If applicable, do you need a dev/dist directory - Do you want a $tlp.staging.apache.org (Just maps to another SVN url, like $tlp/site/branche/staging) Notes to self current process: - Add new paths to /etc/svnwcsub.conf - Checkout svn paths to /x1/tmp - mv /x1/www/$tlp old-site mv /x1/tmp/$tlp /x1/www/$tlp - chown -R svnwc /x1/www/$tlp - /etc/init.d/svnwcsub restart ---End Message--- smime.p7s Description: S/MIME Cryptographic Signature
Re: svn commit: r820427 - in /httpd/httpd/trunk/modules: cluster/mod_heartmonitor.c core/mod_watchdog.c core/mod_watchdog.h
On Wed, Sep 30, 2009 at 9:56 PM, Guenter Knauf fua...@apache.org wrote: Hi Jeff, traw...@apache.org schrieb: Author: trawick Date: Wed Sep 30 20:00:37 2009 New Revision: 820427 URL: http://svn.apache.org/viewvc?rev=820427view=rev Log: change the callable functions in the mod_watchdog API to optional hooks to avoid module ordering or other symbol resolution issues; affected: ap_watchdog_get_instance ap_watchdog_register_callback ap_watchdog_set_callback_interval Modified: httpd/httpd/trunk/modules/cluster/mod_heartmonitor.c httpd/httpd/trunk/modules/core/mod_watchdog.c httpd/httpd/trunk/modules/core/mod_watchdog.h this breaks NetWare export list; and I did spent hours with Rainer last time get the mod_watchdog exported symbols in; can you perhaps help a bit with the awk stuff - I'm no expert with this; see: http://svn.apache.org/viewvc?rev=820503view=rev where I started with it, but too late to get it right ATM ... What is the symptom? The AP_WD_DECLARE stuff is still needed for the external hooks implemented by mod_watchdog, such as APR_DECLARE_EXTERNAL_HOOK(ap, AP_WD, int, watchdog_init, ( server_rec *s, const char *name, apr_pool_t *pool)) NetWare must already support APR_DECLARE_OPTIONAL_FN one way or another, long before this change. I'm unable to tell how mod_watchdog's use of that is different from existing modules, such as mod_ldap or mod_ssl or core.
simple MPM requires apr-trunk
So, what do we want to say is our earliest version of APR required for trunk (and 2.4)?? I'd like for us to really start looking at getting 2.4 out, but that means some APR dependencies, esp if we want Simple to be viable for lots of people.
Re: simple MPM requires apr-trunk
Jim Jagielski wrote: So, what do we want to say is our earliest version of APR required for trunk (and 2.4)?? I'd like for us to really start looking at getting 2.4 out, but that means some APR dependencies, esp if we want Simple to be viable for lots of people. The session stuff needs at least APR v1.4. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: simple MPM requires apr-trunk
On Oct 1, 2009, at 9:15 AM, Graham Leggett wrote: Jim Jagielski wrote: So, what do we want to say is our earliest version of APR required for trunk (and 2.4)?? I'd like for us to really start looking at getting 2.4 out, but that means some APR dependencies, esp if we want Simple to be viable for lots of people. The session stuff needs at least APR v1.4. Yeah, but do we want to require 1.4, which means backporting the pollcb stuff, or do we want to require 2.0, which means httpd 2.4 will be pushed out even further...?
Re: slotmem improving doall
On Oct 1, 2009, at 3:44 AM, jean-frederic clere wrote: On 09/30/2009 06:18 PM, Jim Jagielski wrote: On Sep 29, 2009, at 5:23 AM, jean-frederic clere wrote: Hi, I would like to change the doall / ap_slotmem_callback_fn_t logic. For the moment we can't stop the doall loop, but it could be interesting to do so (for example while search for a value in the slotmems). My idea is to return APR_SUCCESS when done and APR_INCOMPLETE if we want to go on doing the loop. How would it be re-entrant? hmmm... Well the caller would have to solve that problem, it is a loop calling a callback, no? I mean if doall returns APR_INCOMPLETE, it means that it stopped at some point within the loop. But how would the caller know where and how would the caller re-start the loop but say start here instead? Or do you mean that doall would always return APR_SUCCESS but the internal loop of doall could terminate somewhere within the loop?
Re: mod_serf uses non-public API
On Sep 30, 2009, at 9:45 PM, Guenter Knauf wrote: Paul, Paul Querna schrieb: very likely, mod_serf in its current for should just be polished to replace mod_proxy_*, and all of the async stuff should be pushed towards the MPMs.. well the question is: do we want to export ap_process_request_after_handler() in the future, and if so we should AP_DECLARE it; I've just found that test/mod_dial_up.c uses this function too in line 119 ... IMO, -0. The more we leak the internals, the less we can change the internals. That is, if we allow people to use these kinds of internals, then they will, and we don't want 'em to :)
Re: simple MPM requires apr-trunk
Jim Jagielski wrote: Yeah, but do we want to require 1.4, which means backporting the pollcb stuff, or do we want to require 2.0, which means httpd 2.4 will be pushed out even further...? I'd say backport the pollcb stuff. httpd v2.3.x alphas are out the door, while apr v2.x alphas aren't. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: slotmem improving doall
On 10/01/2009 04:06 PM, Jim Jagielski wrote: On Oct 1, 2009, at 3:44 AM, jean-frederic clere wrote: On 09/30/2009 06:18 PM, Jim Jagielski wrote: On Sep 29, 2009, at 5:23 AM, jean-frederic clere wrote: Hi, I would like to change the doall / ap_slotmem_callback_fn_t logic. For the moment we can't stop the doall loop, but it could be interesting to do so (for example while search for a value in the slotmems). My idea is to return APR_SUCCESS when done and APR_INCOMPLETE if we want to go on doing the loop. How would it be re-entrant? hmmm... Well the caller would have to solve that problem, it is a loop calling a callback, no? I mean if doall returns APR_INCOMPLETE, it means that it stopped at some point within the loop. Yes But how would the caller know where and how would the caller re-start the loop but say start here instead? That would be the problem of the caller. If the callback stops the doall loop it should have the logic to skip the slots it already processed no? Or do you mean that doall would always return APR_SUCCESS but the internal loop of doall could terminate somewhere within the loop? That was my first idea... If we choose to go that way it is easy :-) Cheers Jean-Frederic
Re: simple MPM requires apr-trunk
On Thu, Oct 1, 2009 at 9:11 AM, Jim Jagielski j...@jagunet.com wrote: So, what do we want to say is our earliest version of APR required for trunk (and 2.4)?? I'd like for us to really start looking at getting 2.4 out, but that means some APR dependencies, esp if we want Simple to be viable for lots of people. The minimal APR-trunk code in Simple is a run-time mechanism to check for the required pollset capabilities. It is nicer in some respects than a configure-time check since there's no proper APR check available during configure, but it isn't worth requiring a certain level of APR for httpd so that this check will work.
Re: simple MPM requires apr-trunk
On Thu, Oct 1, 2009 at 10:18 AM, Graham Leggett minf...@sharp.fm wrote: Jim Jagielski wrote: Yeah, but do we want to require 1.4, which means backporting the pollcb stuff, or do we want to require 2.0, which means httpd 2.4 will be pushed out even further...? I'd say backport the pollcb stuff. httpd v2.3.x alphas are out the door, while apr v2.x alphas aren't. I generally agree with backporting pollcb to apr 1.4.x, as long as there is interest in supporting Simple as a production MPM in the 2.4.x timeframe (no idea here of the status of Simple).
Re: simple MPM requires apr-trunk
On Thu, Oct 1, 2009 at 11:09 AM, Jeff Trawick traw...@gmail.com wrote: On Thu, Oct 1, 2009 at 10:18 AM, Graham Leggett minf...@sharp.fm wrote: Jim Jagielski wrote: Yeah, but do we want to require 1.4, which means backporting the pollcb stuff, or do we want to require 2.0, which means httpd 2.4 will be pushed out even further...? I'd say backport the pollcb stuff. httpd v2.3.x alphas are out the door, while apr v2.x alphas aren't. I generally agree with backporting pollcb to apr 1.4.x you guys are confusing me ;) pollcb is in 1.3.x even; AFAIK it is just APR_POLLSET_NODEFAULT that simple wants from later APR
mod_fcgid - how to limit max processes per fcgi image
With mod_fastcgi I can to the following: FastCgiServer /usr/local/onelan/html/dsm.fcgi -processes 1 -idle-timeout 200 FastCgiServer /usr/local/onelan/html/dsmxml.fcgi -processes 1 -idle-timeout 30 Which creates two servers running waiting for request with only once instance of each. I cannot see how to achieve the same result with mod_fcgid. The promising MaxProcessCount seems to apply to all processes which is not what I want. I assume that if I set MaxProcessCount to 2 then I might get two dsm.fcgi processor of one of each. Is there a way to limit max processes per image? Barry
Re: mod_fcgid - how to limit max processes per fcgi image
On Thu, Oct 1, 2009 at 11:28 AM, Barry Scott barry.sc...@onelan.co.ukwrote: With mod_fastcgi I can to the following: FastCgiServer /usr/local/onelan/html/dsm.fcgi -processes 1 -idle-timeout 200 FastCgiServer /usr/local/onelan/html/dsmxml.fcgi -processes 1 -idle-timeout 30 Which creates two servers running waiting for request with only once instance of each. I cannot see how to achieve the same result with mod_fcgid. The promising MaxProcessCount seems to apply to all processes which is not what I want. I assume that if I set MaxProcessCount to 2 then I might get two dsm.fcgi processor of one of each. Is there a way to limit max processes per image? close (and probably close enough) See http://httpd.apache.org/mod_fcgid/mod/mod_fcgid.html#fcgiddefaultmaxclassprocesscount
Re: mod_fcgid - how to limit max processes per fcgi image
Jeff Trawick wrote: On Thu, Oct 1, 2009 at 11:28 AM, Barry Scott barry.sc...@onelan.co.uk mailto:barry.sc...@onelan.co.uk wrote: With mod_fastcgi I can to the following: FastCgiServer /usr/local/onelan/html/dsm.fcgi -processes 1 -idle-timeout 200 FastCgiServer /usr/local/onelan/html/dsmxml.fcgi -processes 1 -idle-timeout 30 Which creates two servers running waiting for request with only once instance of each. I cannot see how to achieve the same result with mod_fcgid. The promising MaxProcessCount seems to apply to all processes which is not what I want. I assume that if I set MaxProcessCount to 2 then I might get two dsm.fcgi processor of one of each. Is there a way to limit max processes per image? close (and probably close enough) See http://httpd.apache.org/mod_fcgid/mod/mod_fcgid.html#fcgiddefaultmaxclassprocesscount That works for me. Thanks. I must say that I prefer the flexibility of mod_fastcgi in setting up the process limits / image. Barry
[mod_fcgid proposal] defining processing options for particular commands
(instead of based on uri or vhost) FCGIDCommand /path/to/command IdleTimeout n MaxProcessLifetime n MinProcesses n MaxProcesses n MaxRequestsPerProcess n InitialEnv var[=val] ... class (the names of these options follow my proposal for the names of existing directives ;) ) When a command is to be started by mod_fcgid, any options specified for the command on this directive override those defined for the uri, vhost, global, or the defaults. When a wrapper is used, it is that wrapper which must be specified on this directive. This directive is not required unless one or more options must be customized for a command. Initially this would be allowed only in global sections. InitialEnv can be repeated. Regarding *class*: Something is needed to disable or alter existing management of applications based on their class. Currently a class is limited to the processes started by the same command within the same vhost (except when ServerName isn't specified) with the same identity. One possibility is to provide an option to ignore the vhost name when managing the class (IgnoreVHost or ClassIsGlobal). Another possibility is to set the name of the class to be used in lieu of the virtual host (ClassName foo), which could be used to the same effect but might be more useful in the future when the process manager can see per-server configs (for existing directives as well as FCGIDCommand). None of this would affect the identity checks. (Processes with different uid/gid would never be considered to be in the same class.)
Re: slotmem improving doall
On Oct 1, 2009, at 10:21 AM, jean-frederic clere wrote: I mean if doall returns APR_INCOMPLETE, it means that it stopped at some point within the loop. Yes But how would the caller know where and how would the caller re-start the loop but say start here instead? That would be the problem of the caller. If the callback stops the doall loop it should have the logic to skip the slots it already processed no? Yeah, but the params to doall() don't provide enough info for that. Or do you mean that doall would always return APR_SUCCESS but the internal loop of doall could terminate somewhere within the loop? That was my first idea... If we choose to go that way it is easy :-) OK... how about if we have the doall callback return an apr_status_t and the internal loop in the doalls continue the loop with an APR_SUCCESS and immediately stop on anything else (and return that to the orig callee). So APR_SUCCESS means I went through each element of the slot, APR_INCOMPLETE means I stopped somewhere inside there and all all others (like APR_EGENERAL) mean something that hopefully makes sense to the callee :)
Re: simple MPM requires apr-trunk
On Oct 1, 2009, at 11:14 AM, Jeff Trawick wrote:
On Thu, Oct 1, 2009 at 11:09 AM, Jeff Trawick traw...@gmail.com
wrote:
On Thu, Oct 1, 2009 at 10:18 AM, Graham Leggett minf...@sharp.fm
wrote:
Jim Jagielski wrote:
Yeah, but do we want to require 1.4, which means backporting the
pollcb stuff, or do we want to require 2.0, which means httpd 2.4
will be pushed out even further...?
I'd say backport the pollcb stuff. httpd v2.3.x alphas are out the
door,
while apr v2.x alphas aren't.
I generally agree with backporting pollcb to apr 1.4.x
you guys are confusing me ;)
pollcb is in 1.3.x even; AFAIK it is just APR_POLLSET_NODEFAULT that
simple wants from later APR
It's this:
int good_methods[] = {APR_POLLSET_KQUEUE, APR_POLLSET_PORT,
APR_POLLSET_EPOLL};
and the use of apr_pollcb_create_ex()
Re: simple MPM requires apr-trunk
On Thu, Oct 1, 2009 at 3:10 PM, Jim Jagielski j...@jagunet.com wrote:
On Oct 1, 2009, at 11:14 AM, Jeff Trawick wrote:
On Thu, Oct 1, 2009 at 11:09 AM, Jeff Trawick traw...@gmail.com wrote:
On Thu, Oct 1, 2009 at 10:18 AM, Graham Leggett minf...@sharp.fm wrote:
Jim Jagielski wrote:
Yeah, but do we want to require 1.4, which means backporting the
pollcb stuff, or do we want to require 2.0, which means httpd 2.4
will be pushed out even further...?
I'd say backport the pollcb stuff. httpd v2.3.x alphas are out the door,
while apr v2.x alphas aren't.
I generally agree with backporting pollcb to apr 1.4.x
you guys are confusing me ;)
pollcb is in 1.3.x even; AFAIK it is just APR_POLLSET_NODEFAULT that
simple wants from later APR
It's this:
int good_methods[] = {APR_POLLSET_KQUEUE, APR_POLLSET_PORT,
APR_POLLSET_EPOLL};
and the use of apr_pollcb_create_ex()
yeah
Re: [mod_fcgid] Cleaning up configuration directive names
On Tuesday 29 September 2009 4:20:49 pm you wrote:
On Tue, Sep 29, 2009 at 4:59 PM, Ricardo Cantu rica...@smartcsc.com wrote:
On Tuesday 29 September 2009 2:31:21 pm Jeff Trawick wrote:
ZombieScanInterval (leave alone until processes can be reaped
differently)
Working on a patch for this one. Don't want to duplicate work, so let me
know
if anybody else is working on this.
not me
I hope that, for Unix, processes can be reaped as with the MPMs: instead of
asking if a specific pid has exited (for each pid in the list), ask if any
pid has exited and if so find it in the list and handle.
Well, here it is. My patch to reap the children when they exit rather than
check the list for zombies. Before I take out the old logic for the zombie
scan I would like to hear some input on the code.
basically,
apr_proc_other_child_register() - to register a callback when child exits.
sigaction(SIGCHLD, sa, NULL) - to listen for children dying.
apr_proc_other_child_refresh_all(APR_OC_REASON_RESTART) - called when SIGCHLD
received so callback will be called on the correct registered child.
fcgid_child_maint - The callback. Cleans up the various lists and prints out
log info.
And that's it.
Index: modules/fcgid/fcgid_proc_unix.c
===
--- modules/fcgid/fcgid_proc_unix.c (revision 820820)
+++ modules/fcgid/fcgid_proc_unix.c (working copy)
@@ -58,6 +58,92 @@
static int g_process_counter = 0;
static apr_pool_t *g_inode_cginame_map = NULL;
+static void
+move_idle_to_free(server_rec * main_server, fcgid_procnode * procnode)
+{
+ fcgid_procnode *previous_node, *current_node, *next_node;
+ fcgid_procnode *free_list_header, *proc_table;
+
+ proc_table = proctable_get_table_array();
+ previous_node = proctable_get_idle_list();
+ free_list_header = proctable_get_free_list();
+
+ safe_lock(main_server);
+ current_node = proc_table[previous_node-next_index];
+ while (current_node != proc_table) {
+next_node = proc_table[current_node-next_index];
+
+if (procnode == current_node) {
+/* Unlink from idle list */
+ previous_node-next_index = current_node-next_index;
+
+/* Link to free list */
+ current_node-next_index = free_list_header-next_index;
+ free_list_header-next_index = current_node - proc_table;
+
+ break;
+} else
+ previous_node = current_node;
+
+current_node = next_node;
+ }
+ safe_unlock(main_server);
+}
+
+static void fcgid_child_maint(int reason, void *data, apr_wait_t status)
+{
+ fcgid_procnode *procnode = data;
+ int exitcode;
+ apr_exit_why_e exitwhy;
+
+ if (WIFEXITED(status)) {
+exitcode = WEXITSTATUS(status);
+exitwhy = APR_PROC_EXIT;
+ } else {
+exitcode = WTERMSIG(status);
+exitwhy = APR_PROC_SIGNAL;
+ }
+
+ switch (reason) {
+ case APR_OC_REASON_DEATH:
+ case APR_OC_REASON_LOST:
+
+ /* Log why and how it die */
+proc_print_exit_info(procnode, exitcode, exitwhy, procnode-main_server);
+
+ /* Register the death */
+register_termination(procnode-main_server, procnode);
+
+ /* Destroy pool */
+apr_pool_destroy(procnode-proc_pool);
+procnode-proc_pool = NULL;
+
+ /* Fix lists */
+move_idle_to_free(procnode-main_server, procnode);
+
+if (reason == APR_OC_REASON_DEATH) {
+ ap_log_error(APLOG_MARK, APLOG_INFO, 0, NULL,
+ mod_fcgid: Pid: %d got APR_OC_REASON_DEATH, procnode-proc_id-pid);
+} else {
+ ap_log_error(APLOG_MARK, APLOG_INFO, 0, NULL,
+ mod_fcgid: Pid: %d got APR_OC_REASON_LOST, procnode-proc_id-pid);
+}
+break;
+
+ case APR_OC_REASON_RESTART:
+
+ap_log_error(APLOG_MARK, APLOG_INFO, 0, NULL,
+ mod_fcgid: Pid: %d got APR_OC_REASON_RESTART, procnode-proc_id-pid);
+break;
+
+ case APR_OC_REASON_UNREGISTER:
+
+ap_log_error(APLOG_MARK, APLOG_INFO, 0, NULL,
+ mod_fcgid: Pid: %d got APR_OC_REASON_UNREGISTER, procnode-proc_id-pid);
+break;
+ }
+}
+
static apr_status_t ap_unix_create_privileged_process(apr_proc_t *newproc,
const char *progname,
const char *const *args,
@@ -382,6 +468,10 @@
}
}
+/* setup handler for child death */
+apr_proc_other_child_register(procnode-proc_id, fcgid_child_maint,
+ procnode, NULL, procnode-proc_pool);
+
/* Set the (deviceid, inode) - fastcgi path map for log */
apr_snprintf(key_name, _POSIX_PATH_MAX, %lX%lX,
(unsigned long) procnode-inode,
@@ -457,7 +547,7 @@
apr_exit_why_e exitwhy;
rv = apr_proc_wait(procnode-proc_id, exitcode, exitwhy, APR_NOWAIT);
-if (rv == APR_CHILD_DONE || rv == APR_EGENERAL) {
+if (rv != APR_CHILD_NOTDONE) {
/*
[mod_fcgid patch] reap children without the zombie scan
(just fixing subject)
On Thu, Oct 1, 2009 at 7:55 PM, Ricardo Cantu rica...@smartcsc.com wrote:
On Tuesday 29 September 2009 4:20:49 pm you wrote:
On Tue, Sep 29, 2009 at 4:59 PM, Ricardo Cantu rica...@smartcsc.com
wrote:
On Tuesday 29 September 2009 2:31:21 pm Jeff Trawick wrote:
ZombieScanInterval (leave alone until processes can be reaped
differently)
Working on a patch for this one. Don't want to duplicate work, so let
me
know
if anybody else is working on this.
not me
I hope that, for Unix, processes can be reaped as with the MPMs: instead
of
asking if a specific pid has exited (for each pid in the list), ask if
any
pid has exited and if so find it in the list and handle.
Well, here it is. My patch to reap the children when they exit rather than
check the list for zombies. Before I take out the old logic for the zombie
scan I would like to hear some input on the code.
basically,
apr_proc_other_child_register() - to register a callback when child exits.
sigaction(SIGCHLD, sa, NULL) - to listen for children dying.
apr_proc_other_child_refresh_all(APR_OC_REASON_RESTART) - called when
SIGCHLD
received so callback will be called on the correct registered child.
fcgid_child_maint - The callback. Cleans up the various lists and prints
out
log info.
And that's it.
Index: modules/fcgid/fcgid_proc_unix.c
===
--- modules/fcgid/fcgid_proc_unix.c (revision 820820)
+++ modules/fcgid/fcgid_proc_unix.c (working copy)
@@ -58,6 +58,92 @@
static int g_process_counter = 0;
static apr_pool_t *g_inode_cginame_map = NULL;
+static void
+move_idle_to_free(server_rec * main_server, fcgid_procnode * procnode)
+{
+ fcgid_procnode *previous_node, *current_node, *next_node;
+ fcgid_procnode *free_list_header, *proc_table;
+
+ proc_table = proctable_get_table_array();
+ previous_node = proctable_get_idle_list();
+ free_list_header = proctable_get_free_list();
+
+ safe_lock(main_server);
+ current_node = proc_table[previous_node-next_index];
+ while (current_node != proc_table) {
+next_node = proc_table[current_node-next_index];
+
+if (procnode == current_node) {
+/* Unlink from idle list */
+ previous_node-next_index = current_node-next_index;
+
+/* Link to free list */
+ current_node-next_index = free_list_header-next_index;
+ free_list_header-next_index = current_node - proc_table;
+
+ break;
+} else
+ previous_node = current_node;
+
+current_node = next_node;
+ }
+ safe_unlock(main_server);
+}
+
+static void fcgid_child_maint(int reason, void *data, apr_wait_t status)
+{
+ fcgid_procnode *procnode = data;
+ int exitcode;
+ apr_exit_why_e exitwhy;
+
+ if (WIFEXITED(status)) {
+exitcode = WEXITSTATUS(status);
+exitwhy = APR_PROC_EXIT;
+ } else {
+exitcode = WTERMSIG(status);
+exitwhy = APR_PROC_SIGNAL;
+ }
+
+ switch (reason) {
+ case APR_OC_REASON_DEATH:
+ case APR_OC_REASON_LOST:
+
+ /* Log why and how it die */
+proc_print_exit_info(procnode, exitcode, exitwhy, procnode-main_server);
+
+ /* Register the death */
+register_termination(procnode-main_server, procnode);
+
+ /* Destroy pool */
+apr_pool_destroy(procnode-proc_pool);
+procnode-proc_pool = NULL;
+
+ /* Fix lists */
+move_idle_to_free(procnode-main_server, procnode);
+
+if (reason == APR_OC_REASON_DEATH) {
+ ap_log_error(APLOG_MARK, APLOG_INFO, 0, NULL,
+ mod_fcgid: Pid: %d got APR_OC_REASON_DEATH, procnode-proc_id-pid);
+} else {
+ ap_log_error(APLOG_MARK, APLOG_INFO, 0, NULL,
+ mod_fcgid: Pid: %d got APR_OC_REASON_LOST, procnode-proc_id-pid);
+}
+break;
+
+ case APR_OC_REASON_RESTART:
+
+ap_log_error(APLOG_MARK, APLOG_INFO, 0, NULL,
+ mod_fcgid: Pid: %d got APR_OC_REASON_RESTART, procnode-proc_id-pid);
+break;
+
+ case APR_OC_REASON_UNREGISTER:
+
+ap_log_error(APLOG_MARK, APLOG_INFO, 0, NULL,
+ mod_fcgid: Pid: %d got APR_OC_REASON_UNREGISTER, procnode-proc_id-pid);
+break;
+ }
+}
+
static apr_status_t ap_unix_create_privileged_process(apr_proc_t *newproc,
const char *progname,
const char *const *args,
@@ -382,6 +468,10 @@
}
}
+/* setup handler for child death */
+apr_proc_other_child_register(procnode-proc_id, fcgid_child_maint,
+ procnode, NULL, procnode-proc_pool);
+
/* Set the (deviceid, inode) - fastcgi path map for log */
apr_snprintf(key_name, _POSIX_PATH_MAX, %lX%lX,
(unsigned long) procnode-inode,
@@ -457,7 +547,7 @@
apr_exit_why_e exitwhy;
rv = apr_proc_wait(procnode-proc_id, exitcode, exitwhy,
