Hello, I've been trying to achieve truly transparent zero downtime deploys with Unicorn and Rails for some time now (using SIGUSR2 and SIGQUIT strategy) and I've always hit the problem of my "last worker sends SIGQUIT to the old master" logic being executed way too soon.
In particular, I tried killing the old master in: * before_fork() -- approx. 2 minute downtime * after_fork() -- approx. 2 minute downtime * storing the old-master-killing logic inside a lambda in after_fork() (for the last worker only) and later executing that lambda in Rails' config.after_initialize() hook -- approx. 20 second downtime As you can see, the more I delayed the execution of that "killing the old master" logic, the closer I got to zero downtime deploys. In this manner, I request the addition of a when_ready() hook which is executed just after Unicorn prints "worker=# ready!" to its error log inside Unicorn::HttpServer#worker_loop(). I am happy to implement this (with tests) and submit a patch, but I first wanted to know your opinion on this approach. (I should note that my unicorn setup does not run very close to the memory limit of its host; instead, the amount of free memory is more than double of the current unicorn memory footprint, so I can safely spawn a second set of Unicorn master + workers (via SIGUSR2) without worrying about the SIGTTOU before_fork() strategy shown in the Unicorn configuration example.) Thanks for your consideration. _______________________________________________ mongrel-unicorn mailing list [email protected] http://rubyforge.org/mailman/listinfo/mongrel-unicorn
