Re: Debugging COMM:START-UP-SERVER hang

Martn spake:
>> Thanks Martin! Like I mentioned earlier, new connections weren't htting
>> the ACCEPT phase. There's a little tool `cgi-fastcgi -bind` which can mock
>> a FCGI process. That was failing at the CONNECT phase.

> Is there an error message from the failing CONNECT phase?

Well, not from the client side... that just hangs waiting to connect.
That's why I'm thinking your earlier idea of file handlers / zombie sockets
might be the secret.

> Maybe the problem is the (ignore-errors (close connection) ...)?  If there is
> any output in the stream's buffer, then close will try to write it before
> closing the handle.  Writing to a socket might cause an error if the other end
> of the connection has been closed already.  If you don't care about flushing,
> then use (close connection :abort t).

Oh good point! That's probably why I had to double-wrap the HANDLER-BIND
(in the socket acceptance and again in the procesing). I assumed there were
separate socket errors in each... but it sounds like it could have been a new
error propagating from my faulty CLOSE instead.

> Also, log errors rather than silently ignoring them.

Sure ... and do what with them?

The errors from that section are hangups from the outer web server
(Caddy in my case). I can't do anything with the info, since my app isn't
directly communicating with the outside world. My app is proxied
by another web server. CADDY in my case, but NGINX or LIGHTTPD
also work I'm told.

You are right though, it'd be better to know *how many* errors
I'm seeing rather than just swallowing the lot.

A.