<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 24, 2015 at 6:01 PM, Maxim Dounin <span dir="ltr"><<a href="mailto:mdounin@mdounin.ru" target="_blank">mdounin@mdounin.ru</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div id=":wy" class="" style="overflow:hidden">If there are good reasons why the termination takes so long - we<br>
may consider adding another iteration.  Otherwise - yes, it'll<br>
remain fixed.</div></blockquote></div><br><div class="gmail_extra">I have a test to see if the module shuts down properly upon receiving SIGTERM.</div><div class="gmail_extra">This test starts up nginx plus a lot of synthetic load in parallel. </div><div class="gmail_extra">The SIGTERM signal is sent a few seconds after both are up and running, at which point lots of work will have queued up in the module's worker threads.</div><div class="gmail_extra">Without valgrind, the current timespan nginx allows for wrapping up is (more then) enough, but with valgrind, unwinding takes a longer time. Sometimes less, sometimes more than the current limit nginx imposes, which makes the test unreliable.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Does that count as a good reason? </div></div></div>