On 01.11.05 17:17 +0100, Kjell N wrote:

> I compared the processlist (ps -A) before and after reboot and
> found a diff.   One process is missing before reboot, that is
> running on a newly rebooted system:
> 136  ??  Is     0:00.01 /usr/local/sbin/mini_httpd -S -a -M 0 -E
> /var/etc/cer
> 
> Is there still a problem with mini_httpd?

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.

Then see if it crashes again and let us know. Oh, and please don't
cross-post anymore.

- Manuel