Strange behavior with custom module and http proxy

Brian Bruns brian at
Tue Dec 22 07:23:56 MSK 2009

Hi Piotr,

I have created a (very) small module that demonstrates the problem.
It can be downloaded here:

I've included a README on how to set up the module, and how to
reproduce the problem.

So, if I open the URL http://localhost:4242/bogus/a it returns right away.

If I open http://localhost:4242/cache/bogus/b which goes through the
http proxy caching it hangs for 30 seconds until the child process
(bogochild) exits after sleeping.

Also, I did test not forking in the child (which basically makes the
child a "sleep 30") with a small adjustment to the module (removing
the waitpid) and the problem still persists.

Thanks again for the help!


2009/12/21 Brian Bruns <brian at>:
> That is the confusing part to me.  SIGCHLD is called on the death of
> the parent but not the death of the grandchild (correctly) and the
> signal handler with waitpid() is called immediately, not after the 60
> second delay.
> The module is destined to be released but I'm not quite ready for it
> just yet.  I will roll up a minimal module that replicates the
> behavior and post that.
> Thank you for the help.
> Brian
> 2009/12/21 Piotr Sikora <piotr.sikora at>:
>>> It's almost as if nginx
>>> is doing a wait() for the child before closing the request, although I
>>> know the child has been reaped earlier and the grandchild is now a
>>> child of init.
>> It is indeed calling waitpid() after receiving SIGCHLD, but this shouldn't
>> be a problem. Could you check if this happens also with single-fork()
>> (without spawning grandchild)?
>>> Like I said, I only noticed the behavior when using http proxy
>>> caching, so the problem has existed for me all along without my being
>>> aware of it.
>> If you don't want to share your module, could you make module with minimal
>> functionality which reproduces this behavior?
>> Best regards,
>> Piotr Sikora < piotr.sikora at >
>> _______________________________________________
>> nginx mailing list
>> nginx at

More information about the nginx mailing list