The AOLServer code for signal handling is very simple. The
functions NsBlockSignals and NsHandleSignals are included bellow. These
functions contain all the signal handling that is relevant to this issue.
AOLServer does more funny things when it exec()s an external program, but
I am not exec()ing anythig, so the code below is all that applies.
Some notes:
- sigwait() is actually NsHandleSignals. They forgot to update the
comment at some point :-0
- NS_SIGTCL = SIGUSR2
- NS_SIGHUP = SIGHUP
- ns_sigmask = pthread_sigmask
- ns_sigwait = sigwait
The main() function first calls NsBlockSignals, then starts a
thread that will receive and dispatch connections by launching new
connection threads. After that, main() calls NsHandleSignals where it
stays until the server is shut down. Therefore, all threads that will call
the JVM will have the SIGHUP, SIGPIPE, SIGTERM, SIGINT and SIGUSR2 signals
masked.
One cannot expect a web server not to handle signals like SIGHUP
or TERM, so I don't see why this is "bad, bad, bad" in principle. The fact
that the JVM expects to run alone and handle all signals itself is IMHO
"bad, ugly, nasty" :-) I think that the AOLServer does the right thing in
protecting threads other than main from signals...
I am starting the JVM from main() between the calls to
NsBlockSignals and NsHandleSignals. That's because all modules get
initialized there. So, it should see that some signals are blocked. But I
guess that it doesn't check the mask...
Any hints from here on?
TIA,
Vasile
-------- Code below -------
/*
*----------------------------------------------------------------------
*
* NsBlockSignals --
*
* Block signals at startup.
*
* Results:
* None.
*
* Side effects:
* Signals will be pending until NsHandleSignals.
*
*----------------------------------------------------------------------
*/
void
NsBlockSignals(int debug)
{
sigset_t set;
int i;
/*
* Block SIGHUP, SIGPIPE, SIGTERM, and SIGINT. This mask is
* inherited by all subsequent threads so that only this
* thread will catch the signals in the sigwait() loop below.
* Unfortunately this makes it impossible to kill the
* server with a signal other than SIGKILL until startup
* is complete.
*/
debugMode = debug;
sigemptyset(&set);
sigaddset(&set, SIGPIPE);
sigaddset(&set, SIGTERM);
sigaddset(&set, NS_SIGHUP);
sigaddset(&set, NS_SIGTCL);
if (!debugMode) {
/* NB: Don't block SIGINT in debug mode for Solaris dbx. */
sigaddset(&set, SIGINT);
}
ns_sigmask(SIG_BLOCK, &set, NULL);
}
/*
*----------------------------------------------------------------------
*
* NsHandleSignals --
*
* Loop forever processing signals until a term signal
* is received.
*
* Results:
* None.
*
* Side effects:
* HUP and/or Tcl init callbacks may be called.
*
*----------------------------------------------------------------------
*/
void
NsHandleSignals(void)
{
sigset_t set;
int err, sig;
/*
* Once the server is started, the initial thread will just
* endlessly wait for Unix signals, calling NsRunSignalProcs()
* or NsTclRunInits() when requested.
*/
sigemptyset(&set);
sigaddset(&set, SIGTERM);
sigaddset(&set, SIGHUP);
sigaddset(&set, NS_SIGTCL);
if (!debugMode) {
sigaddset(&set, SIGINT);
}
do {
sig = 0;
err = ns_sigwait(&set, &sig);
if (err != 0 && err != EINTR) {
Ns_Fatal("main: sigwait() error: %s", strerror(err));
} else if (sig == NS_SIGHUP) {
NsRunSignalProcs();
} else if (sig == NS_SIGTCL) {
NsTclRunInits();
}
} while (sig != SIGTERM && sig != SIGINT);
/*
* At this point the server is shutting down. First reset
* the default signal handlers so if the user is impatient
* they can send another SIGTERM and cause immediate shutdown.
*/
sigemptyset(&set);
sigaddset(&set, SIGHUP);
sigaddset(&set, SIGTERM);
if (!debugMode) {
sigaddset(&set, SIGINT);
}
ns_sigmask(SIG_UNBLOCK, &set, NULL);
}
-------- That's it --------
On Wed, 17 May 2000, Christopher Smith wrote:
> > If you make sure, you do not mask your SIGUSR1 and SIGUSR2,
> >you should be able to run fine. However, there is one caveat. Linux
> >threads use SIGUSR1 and SIGUSR2 for their internal
> >communication in some products. If your >product also uses them,
> >you should see for alternatives.
>
> Actually, I believe the Linux thread support in glibc no longer uses SIGUSR1
> & 2.
>
> It's more likely his problem is coming from masking all those signals (bad,
> bad, bad) which the JVM needs to have available to it.
>
> The AOLServer's sigwait() is essentially the source of your problems. I'm
> not sure how you'd fix it, as I'm not familiar with the AOLServer code.
>
> --Chris
>
>
----------------------------------------------------------------------
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
