With mod_cgi scripts that do not produce any output over a certain period of time are killed. With mod_cgid they hang forever.
Created attachment 22316 [details] Adding a timeout watch for mod_cgid (first cut) This patch adds a timeout thread to the cgid daemon, which checks for processes that have timedout. A better solution would have been to set a timeout on the receiving socket from cgi. But unfortunately the unix sockets that are used to link the cgi process and handler do not alow SO_SNDTIMEIO and SO_RCVTIMEO to be set. I suspect there are better approaches, please do let me know how else this can be done.
It would be best to make use of the existing nonblock+poll timeout implementation in apr, such that when the apr-wrapped AF_UNIX socket is read from, read will return APR_TIMEUP at the right time. The current apr representation of the AF_UNIX socket may not be the best choice, or we may not be setting it up properly. (Or this may be a hopeless goal without new apis in apr trunk :( ) If at all possible, mod_cgid should avoid threads; having a single-threaded process to fork/setup/exec the children is a feature to avoid unexpected inheritance. One specialized thread to worry about shouldn't be too hard, but even in the current implementation I am hoping the inheritance of the occasional locked state of new mutex would get repaired automatically once the child does exec() and we wouldn't need to use pthread_atfork().
Created attachment 22324 [details] threadless patch for cgid timeout > It would be best to make use of the existing nonblock+poll timeout > implementation in apr Currently, as far as I can see, APR does not know about UNIX sockets, and would have to mess with the private apr headers and datastructures under arch to do it. > If at all possible, mod_cgid should avoid threads; having a single-threaded > process to fork/setup/exec the children is a feature to avoid unexpected > inheritance. Thanks, I hadn't thought about it. I am adding a new patch which checks it using SIGALRM instead.
Created attachment 30110 [details] patch for timeout I have created another patch to fix this bug by adding just one line. The tempsock is wrapped file descriptor, so apr_file_pipe_timeout_set can be used to set timeout. This patch was tested on httpd 2.4.4 and works correctly.
I fear that since mod_cgid has never timed anything out in so many years, that in 2.4 and 2.2 this would have to be based on a new configuration directive. I also see that mod_cgi sets a number of pipe timeouts, and there is also an NPH path where the pipe is created/read.
Committed a version with a new directive to trunk in 1535125, thanks Toshikuni for the patch.
Undo spam change
Please help us to refine our list of open and current defects; this is a mass update of old and inactive Bugzilla reports which reflect user error, already resolved defects, and still-existing defects in httpd. As repeatedly announced, the Apache HTTP Server Project has discontinued all development and patch review of the 2.2.x series of releases. The final release 2.2.34 was published in July 2017, and no further evaluation of bug reports or security risks will be considered or published for 2.2.x releases. All reports older than 2.4.x have been updated to status RESOLVED/LATER; no further action is expected unless the report still applies to a current version of httpd. If your report represented a question or confusion about how to use an httpd feature, an unexpected server behavior, problems building or installing httpd, or working with an external component (a third party module, browser etc.) we ask you to start by bringing your question to the User Support and Discussion mailing list, see [https://httpd.apache.org/lists.html#http-users] for details. Include a link to this Bugzilla report for completeness with your question. If your report was clearly a defect in httpd or a feature request, we ask that you retest using a modern httpd release (2.4.33 or later) released in the past year. If it can be reproduced, please reopen this bug and change the Version field above to the httpd version you have reconfirmed with. Your help in identifying defects or enhancements still applicable to the current httpd server software release is greatly appreciated.