On Mon, Jul 28, 2003 at 03:38:52PM +0100, Brian Candler wrote:
> ISTM that if sqwebmail wants to install cleanup handlers for SIGINT /
> SIGTERM / SIGHUP then it should just cleanup the current request and exit()
> immediatetly, not longjmp back into the main loop.
My proposed patch is below. The fundamental premise is that catch_sig should
exit immediately after cleaning up, rather than returning to the main loop,
and that SIG_PIPE should be ignored when running as fastcgi.
I've gone through a build/rollout and it appears to be working nicely -
Apache has a pool of 8-10 sqwebmail processes and the load average runs up
to about 0.15 - but I'll let you know after a day or so of proper usage.
Although my dev box has had fastcgi running for a while, this is the first
time I've successfully got fastcgi running in a production environment. This
will also give a chance to see if its memory footprint is stable.
Cheers,
Brian.
--- sqwebmail-3.5.3.20030725/sqwebmail/sqwebmail.c.orig Mon Jul 21 20:26:32 2003
+++ sqwebmail-3.5.3.20030725/sqwebmail/sqwebmail.c Mon Jul 28 15:58:32 2003
@@ -2067,10 +2067,8 @@
{
n=n;
cleanup();
- fake_exit(0);
-#if RETSIGTYPE != void
- return (0);
-#endif
+ maildir_cache_cancel();
+ exit(0);
}
static void setlang()
@@ -2211,11 +2209,6 @@
continue;
}
cleanup(); /* make sure we hit it */
-
- signal(SIGHUP, catch_sig);
- signal(SIGINT, catch_sig);
- signal(SIGPIPE, catch_sig);
- signal(SIGTERM, catch_sig);
}
return (0);
#else
@@ -2262,9 +2255,21 @@
ip_addr=getenv("REMOTE_ADDR");
+ /*
+ * Note: if we get a signal during FastCGI processing, this means
+ * means we need to terminate so that the webserver can respawn us.
+ * Exception is SIGPIPE which we just ignore (this is what we get
+ * if we try to write data to a client which goes away before
+ * we finished sending them the reply)
+ */
+
signal(SIGHUP, catch_sig);
signal(SIGINT, catch_sig);
+#if HAVE_LIBFCGI
+ signal(SIGPIPE, SIG_IGN);
+#else
signal(SIGPIPE, catch_sig);
+#endif
signal(SIGTERM, catch_sig);
if (!ip_addr) ip_addr="127.0.0.1";
