Background jobs with #fork

Hongli Lai hongli at
Thu Apr 12 21:15:54 UTC 2012

On Thu, Apr 12, 2012 at 10:39 PM, Eric Wong <normalperson at> wrote:
>> The problem persists even when multiple workers are started. And the
>> problem was not present in the old setup with Passenger.
>> My question: Does Unicorn somehow check/wait for child processes
>> forked by the worker processes?
> Unicorn workers do not explicitly wait on child processes themselves,
> unicorn workers set: trap(:CHLD,"DEFAULT") after forking, even (the
> unicorn master must handle SIGCHLD, of course)
> The difference between nginx+unicorn and Passenger is probabably: nginx
> relies on unicorn generating an EOF to signal the end-of-response (nginx
> <-> unicorn uses HTTP/1.0), this I'm sure about.  I think Passenger uses a
> protocol which can signal the end-of-request inline without relying on
> an EOF on the socket (Hongli can correct me on this if I'm wrong).

We don't. We call #close_write on the socket to prevent this problem.
#close_write calls shutdown(fd, SHUT_WR) which isn't affected by the
number of processes that have inherited the socket handle.

Phusion | Ruby & Rails deployment, scaling and tuning solutions

E-mail: info at
Chamber of commerce no: 08173483 (The Netherlands)

More information about the mongrel-unicorn mailing list