httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stipe Tolj <>
Subject [PATCH] (1.3.x) Cygwin 1.x problems with SIGUSR1 and support for
Date Fri, 08 Jun 2001 01:36:37 GMT
Hi list,

attached is a patch against current stable release 1.3.20 which solves
the reported problems PR#7837 and PR#7838 for the Cygwin 1.x platform.

The changes have been made with portability in mind, they should have
no impact on other platforms.

While producing the current apache_1.3.20-i686-whatever-cygwin.tar.gz
binary package I came accross a couple of problems which have to be
added to produce the Cygwin 1.x binaries out-of-the-box as described
in the binaries.html file on

Here is what has to be changed:

    * src/Configure: added -lgdbm flag to LIBS within the Cygwin
specific block to build mod_auth_dbm within the binary package.

    * src/helpers/ added OS specific CONFIGPARAM value
with reasonable entries to build for Cygwin. (Builds the DLL version
by default)

    * src/helpers/ added simple checking of executable
extensions (.exe) which are used on the Cygwin platform to ensure
those files are copied.

It seems that within
main/http_main.c:perform_idle_server_maintenance() the required
killing of children using "kill([...], SIGUSR1)" seems not to have any
effect on the Cygwin 1.x platform. I noticed this problem on a
productive (WinNT4) machine which usually hangs after about 3-4 weeks
because of too many remaining httpd children. After debugging things I
can say that the SIGUSR1 signal which is sent to the child to be
killed has _no_ effect and hence the scoreboard pool does grow and
exhausts memory.

Here is what I changed to solve things (even if this may not be the
best way):

    * src/include/ap_config.h: added #define HAVE_MMAP,
Cygwin 1.x specific define block

    * main/http_main.c: added #define SIG_IDLE_KILL to reflect the
used signal in case we have idle_count > ap_daemons_max_free and hence
kill the child one by one. Cygwin will use SIGKILL because non of the
other signals seems to have an effect while running.

I would be glad if someone can point me to a solution which would be
more sophisticated.

Wapme Systems AG

Münsterstr. 248
40470 Düsseldorf

Tel: +49-211-74845-0
Fax: +49-211-74845-299

------------------------------------------------------------------- - wherever you are

View raw message