[ previous ] [ next ] [ threads ]
 
 From:  Manuel Kasper <mk at neon1 dot net>
 To:  "Burkhart, John T." <JOHN dot T dot BURKHART at saic dot com>
 Cc:  m0n0wall dash dev at lists dot m0n0 dot ch
 Subject:  RE: [m0n0wall-dev] Unstable mini_httpd for captive portal
 Date:  Sun, 12 Jun 2005 12:23:25 +0200
On 09.06.05 16:33 -0700, Burkhart, John T. wrote:

> ps auxww showed 2739 as /usr/local/sbin/mini_httpd -S -a -M 0 -E
> /var/etc/cert-portal.pem -u root -maxproc 16 -p 8001 -i
> /var/run/mini_httpd.cps.pid
> 
> 
> This happened after pid 2739 died...after the process died a new one
> appeared....pid 3106.
> 
> $ cat /tmp/truss.log
> ...
> SIGNAL 15
> SIGNAL 15
> SIGNAL 15

Thanks for the truss output, John! I can't see anything out of the
ordinary in it - except of course for the fact that mini_httpd
received a SIGTERM, which it dutifully obeyed. For the life of me I
can't figure out what could possibly be sending it that TERM signal,
since the only way to restart the captive portal (thus
killing/restarting mini_httpd) is through manual action in the webGUI.

You say that a new process appeared after the old one died - so that
would mean there was a mini_httpd around, but not accepting
connections? What does "netstat -anf inet" say in that case?

Also, note that when the captive portal is in HTTPS mode, there are
two mini_httpd daemons running: one in HTTP mode on port 8000 (to
intercept outgoing HTTP connections by non-authenticated clients),
and one on port 8001 (in SSL mode). Could it be that the port 8001
mini_httpd is working OK, but instead the one on port 8000 is
misbehaving? (of course that wouldn't explain the SIGTERM) - You can
check that by trying to load https://<m0n0wall-addr>:8001/
In that case, some truss output on the port 8000 mini_httpd would be
helpful too.

- Manuel