On Fri, Oct 16, 2009 at 8:04 PM, Chris Kukuchka <chr...@sequoiagroup.com> wrote:
> Michael B Allen wrote:
>>
>> Can I temporarily disable that SIGTERM so that I can have enough time
>> to attach GDB to the hanging processes?
>>
>
> Mike,
>
> The code which sends the SIGTERM is in mpm_common.c:
>
> static int reclaim_one_pid(pid_t pid, action_t action)
> {
> ...
> case SEND_SIGTERM:
> /* ok, now it's being annoying */
> ap_log_error(APLOG_MARK, APLOG_WARNING,
> 0, ap_server_conf,
> "child process %" APR_PID_T_FMT
> " still did not exit, "
> "sending a SIGTERM",
> pid);
> kill(pid, SIGTERM);
> break;
> ...
> }
>
> The time delay is in this table (also in mpm_common.c):
>
> void ap_reclaim_child_processes(int terminate)
> {
> ...
> struct {
> action_t action;
> apr_time_t action_time;
> } action_table[] = {
> {DO_NOTHING, 0}, /* dummy entry for iterations where we re
> * children but take no action against
> * stragglers
> */
> {SEND_SIGTERM, apr_time_from_sec(3)},
> {SEND_SIGTERM, apr_time_from_sec(5)},
> {SEND_SIGTERM, apr_time_from_sec(7)},
> {SEND_SIGKILL, apr_time_from_sec(9)},
> {GIVEUP, apr_time_from_sec(10)}
> };
> ...
> }
>
> I am not certain, but I would guess changing mpm_common.c would require
> recompiling the full package. Rather than go through that, you might first
> try using gdb to attach to a running lead Apache process and suppress that
> function.
Hi Chris,
Thanks for the references. At least I know it's hard coded and that
trying to backtrace a worker proc in 3 seconds would be completely
hopeless. And I don't see the customer recompiling anything. I'll just
have to find a different angle.
Mike
--
Michael B Allen
Java Active Directory Integration
http://www.ioplex.com/
