Return-Path: Delivered-To: apmail-new-httpd-archive@apache.org Received: (qmail 78366 invoked by uid 500); 14 Jun 2001 16:09:07 -0000 Mailing-List: contact new-httpd-help@apache.org; run by ezmlm Precedence: bulk Reply-To: new-httpd@apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list new-httpd@apache.org Received: (qmail 78113 invoked from network); 14 Jun 2001 16:08:59 -0000 Date: Thu, 14 Jun 2001 09:12:12 -0700 (PDT) From: X-Sender: To: Subject: Re: [PATCH] screw up prefork even more In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N > > > I'm pretty sure that Ryan disagrees with the path I took for SIGHUP, > > > which is to kill everybody we can with the pod (since that is the most > > > clean and reliable mechanism we have) and let > > > ap_reclaim_child_processes() handle the stragglers. > > > > You can't use the pod to gracelessly shutdown the child processes. It > > doesn't do that. The pod will only work for graceful shutdowns. > > that's sort of what I said... we start off like graceful (everybody > that dies from the pod dies cleanly) and then > ap_reclaim_child_processes() knocks everybody else out with SIGTERM If we are going to end up sending the SIGTERM, then why bother with the pod at all? > > There are only two options for gracelessly killing a child process, that I > > know of. > > > > 1) Use signals. > > > > 2) Have a thread that is specifically used to listen for some other > > out-of-band communication. > > > > Since we are in an MPM that doesn't have threads, signals are the only way > > I know of to implement a graceless shutdown. The pod will not be able to > > do this. > > by the way... what are you thinking about w.r.t. threads? I am thinking of doing exactly what we do in threaded, namely a single signal handling thread that does what is required to handle the kill signal. > One thing I wanted to avoid was having a SIGHUP handler in the server > process which calls clean_child_exit(), because we have no idea what > mutexes we were holding before being interrupted by a signal. We ran > into this previously with threaded, and though prefork should have > less chance of this problem we don't know what libc and plugin modules > will be doing. Why didn't we ever see this problem in 1.3? > For graceless shutdown I'm inserting a first step which gets > some of the server processes out of the way before I do what I'm > afraid of. (Yeah, this doesn't make much sense in terms of a 100% > solution. It is more a way to minimize risk.) > > Did you want the SIGHUP handler in the child process to be just_die()? It has to be. IMNSHO, please_die_gracefully should just go away. That is all handled by the pod. I just did a simple search through prefork, and our signals are still really screwed up. :-( This should be relatively simple for the child process, IMO: SIGWINCH use pod SIGTERM just_die For the parent, it gets a bit more complex SIGWINCH use pod to send message to child SIGHUP use pod to send message to child SIGTERM send signal to child process SIGINT if one_process, just_die otherwise, ignore Ryan _______________________________________________________________________________ Ryan Bloom rbb@apache.org 406 29th St. San Francisco, CA 94131 -------------------------------------------------------------------------------