The fix Manuel suggested to try seems to correct the problem on the 3 M0n0 boxes that I'm
running....

They've been running flawlessly for me since replacing the mini_httpd binary.  One of mine was dying
a few times each day.

>>>>>>>>>>>>>>>>>>

There's a rare issue when the maximum number of concurrent
connections to mini_httpd is reached, and one more connection is
accepted, but no request is ever received on that connection (could
be due to a weird client, or one with a flaky [wireless?]
connection). Then an ALRM signal will eventually be triggered to
handle the read timeout, causing the parent process to exit.

<http://m0n0.ch/wall/downloads/mini_httpd.cpfix2> is a version of
mini_httpd that avoids this by simply closing the connection if it's
overloaded, instead of trying to send a 503 message to the client. Of
course if that happens frequently (e.g. because of many people using
the captive portal, or misconfigured clients - Windows Auto Update
Client, for example), the number of concurrent connections must be
increased (I could envision a special option to set the number of
connections to a higher value than 16 on machines that have the
appropriate amount of RAM, and also another feature to limit the
number of concurrent connections per IP address).

Upload mini_httpd.cpfix2 through /exec.php, then run the following
commands:

mv /usr/local/sbin/mini_httpd /usr/local/sbin/mini_httpd.old
cp /tmp/mini_httpd.cpfix2 /usr/local/sbin/mini_httpd
chmod +x /usr/local/sbin/mini_httpd

Then restart the captive portal by clicking "Save" on the setup page.
Don't restart m0n0wall, as that will cause the modified mini_httpd
binary to be lost.

- Manuel