Re: Debugging COMM:START-UP-SERVER hang

I suggest adding the -f option to strace (which will make it show all threads)
and then try to make a new connection to the port to see if it is accepted.

Also, look at the output of netstat -antp (or ss -antp if you don't have
netstat) to check that the process still has a listening socket and that the
system doesn't have too many sockets stuck in strange states like CLOSE_WAIT.

You could also look at the output of lsof -p $pid to check that the process is
not running out of file descriptors.

-- 
Martin Simmons
LispWorks Ltd
http://www.lispworks.com/



>>>>> On Fri, 27 Feb 2026 02:35:15 +0000, Adam Weaver (as adam at cleversure dot com dot au) said:
> 
> Has anyone got any tips for working out why my DELIVERed app hangs after about a week uptime?
> 
> As far as I can tell:
> 
> ```
> (comm:start-up-server :process-name "FCGI" :function #'accept-fcgi-request :service port :reuseport t)
> ```
> 
> stops responding after a week. ish.
> 
> strace wasn't particularly helpful:
> 
> ```
> strace -p 31831
> strace: Process 31831 attached
> restart_syscall(<... resuming interrupted futex ...>) = -1 ETIMEDOUT (Connection timed out)
> futex(0x8e827f8, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 0, {tv_sec=1772158231, tv_nsec=840096000}, FUTEX_BITSET_MATCH_ANY) = -1 ETIMEDOUT (Connection timed out)
> futex(0x8e827f8, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 0, {tv_sec=1772158236, tv_nsec=840336000}, FUTEX_BITSET_MATCH_ANY) = -1 ETIMEDOUT (Connection timed out)
> ```
> 
> which looked identical to strace output from a newly started binary.
> 
> My ACCEPT-FCGI-REQUEST is reasonably benign:
> 
> ```
> (defun accept-fcgi-request (handle)
>   (handler-bind ((error (lambda (c) (declare (ignore c)) (return-from accept-fcgi-request))))
>     (process-fcgi-connection (make-instance 'comm:socket-stream :socket handle :direction :io :element-type '(unsigned-byte 8)))))
> 
> (defun process-fcgi-connection (connection)
>   (handler-bind ((error (lambda (c)
>                           (declare (ignore c))
>                           (ignore-errors (close connection) (return-from process-fcgi-connection))))
>                  (fcgi-close-handle (lambda (c)
>                                       (declare (ignore c))
>                                       (ignore-errors (close connection) (return-from process-fcgi-connection)))))
>     (loop
>       (multiple-value-bind (type id buffer) (read-fcgi-record connection)
>         (handler-bind ((error (lambda (c) (output-fcgi-response nil id connection (princ-to-string c) "text/plain" 503))))
>           (declare (type fixnum type id) (type (array (unsigned-byte 8)) buffer))
>           (case* #'eql type
>             (+fcgi-begin-request+ (fcgi-begin-request id buffer))
>             (+fcgi-abort-request+ (fcgi-abort-request connection id))
>             (+fcgi-end-request+ (fcgi-end-request connection id 0 0))
>             (+fcgi-params+ (fcgi-params id buffer))
>             (+fcgi-stdin+ (fcgi-stdin connection id buffer))
>             (+fcgi-data+ (fcgi-data connection id buffer))
>             (+fcgi-get-values+ (fcgi-get-values connection id buffer))
>             (t (error "Unknown FCGI type ~S" type))))))))
> ```
> 
> with HANDLER-BINDs around socket read points.
> But COMM:START-UP-SERVER spins up a new thread for every ACCEPT (very inefficient I know), so why would
> COMM:START-UP-SERVER stop ACCEPTing new requests?
> 
> I've never had an issue when running locally (emacs/sly) with literal months of uptime.
> Error seems to be in delivered apps only.
> 
> A
> 

_______________________________________________
Lisp Hug - the mailing list for LispWorks users
[email protected]
http://www.lispworks.com/support/lisp-hug.html