On 2022-08-11 11:39 +02, Claudio Jeker <[email protected]> wrote: > On Wed, Aug 10, 2022 at 09:45:44PM +0200, Omar Polo wrote: >> On 2022/08/10 15:07:15 +0200, Claudio Jeker wrote: >> > On Sun, Aug 07, 2022 at 11:10:22AM +0200, Omar Polo wrote: >> > Should slowcgi kill the command if SCRIPT_DONE is not set? >> >> RFC 3875 says that a script should be prepared to handle abnormal >> termination and tha the server acn interrupt or terminate it at any >> time and without warning, so killing the script is a possibility. >> >> However, I'm a bit worried. We could hit the timer not because of a >> faulty script but because an HTTP client is purposefully reading data >> slowly. This could even allow to kill the scripts at specific points. >> Maybe I'm overthinking and it's not an issue. > > The question I have is if scripts properly notice the IO error and > terminate. If a script got stuck somehow and just sits there it will not > realize it got killed. If that process exits at a later point slowcgi will > be confused about a spurious SIGCHLD. > > What would happen if this instead sends a SIGTERM and after 5sec timeout a > SIGKILL to the process? It should result in a proper close of the session > via the usual channels (signal handler, io handler). Isn't that a better > way of handling a timeout?
It was a design decision why back when to ignore the RFC and not kill the script on timeout because it was unclear how many badly behaving scripts there are. I do hope that most people moved to fastcgi by now and maybe it's time to shake out scripts that don't handle termination correctly? This has come up so many times over the years that I suspect I'm the only one worried about misbehaving scripts. So ok, fine, go ahead, terminate & kill after timeout. Btw. it's not getting too confused about a spurious SIGCHLD, it just logs it. -- I'm not entirely sure you are real.
