This bug is reported in The fastcgi-developers mailinglist archive, but misunderstood:The symptom: signal received while waiting in CGI::Fast::new (actually FCGI::Accept) is reported only at the next request. It's not related to safe signals. FCGI::Accept() blocks until the next request and does not allow the perl script to handle the signal. That is because Fast.pm does not set FCGI::Request 's flag to 1 (1 is for FCGI_FAIL_ACCEPT_ON_INTR in fcgi) when not used for en external fastcgi application. When used in a normal dynamic or static application it does not even call FCGI::Request (the constructor) and uses the class method FCGI::Accept with flags=0. The attached patch (against version 1.05 of Fast.pm) fixes this by always using an FCGI object.
Message body not shown because it is not plain text.