<div dir="ltr"><div>Not spinning since then, but that's when that worker (from the old binary) was spawned. It's an old worker spinning.</div><div><br></div><div dir="ltr">Unfortunately there isnt any debug symbols.<br><div><br></div><div>GDB:</div><div><div>(gdb) bt</div><div>#0 0x00007ff842edd016 in ?? ()</div><div>#1 0x0000000040d9ab70 in ?? ()</div><div>#2 0x4096580000000000 in ?? ()</div><div>#3 0x4064000000000000 in ?? ()</div><div>#4 0x00000009413dcda0 in ?? ()</div><div>#5 0x41f975d000000006 in ?? ()</div><div>#6 0x000000004190c148 in ?? ()</div><div>#7 0x00000000413e4580 in ?? ()</div><div>#8 0x40bb6b7840f961c8 in ?? ()</div><div>#9 0x0000000000464000 in ?? ()</div><div>#10 0x00007ffea78d5370 in ?? ()</div><div>#11 0x0000000000000000 in ?? ()</div><div><br></div><div>strace:</div><div>--- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---<br></div><div>rt_sigreturn() = 1094569376</div><div>--- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---</div><div>rt_sigreturn() = 1094569376</div><div>--- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---</div><div>rt_sigreturn() = 1094569376</div><div>--- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---</div><div>rt_sigreturn() = 1094569376</div><div>--- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---</div><div>rt_sigreturn() = 1094569376</div><div>--- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---</div><div>rt_sigreturn() = 1094569376</div><div>--- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---</div><div>rt_sigreturn() = 1094569376</div><div>--- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---</div><div>rt_sigreturn() = 1094569376</div><div>--- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---</div><div>rt_sigreturn() = 1094569376</div></div><div><br></div><div><br></div><div>It is a reduced version (less additional modules) of Openresty so third party module interference is possible. Would there be any thing in particular re; modules I should check for?</div><div><br></div><div>My first step has been trying to work out how to replicate it on demand. Just triggering binary reloads is not enough, something has to happen between them and I'm not yet sure what.</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, May 4, 2019 at 8:52 AM Maxim Dounin <<a href="mailto:mdounin@mdounin.ru">mdounin@mdounin.ru</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello!<br>
<br>
On Thu, May 02, 2019 at 08:51:41PM +1000, Mathew Heard wrote:<br>
<br>
> Got a little bit further and confirmed this is definitely to do with the<br>
> binary upgrade.<br>
> <br>
> www-data 988 99.9 0.7 365124 122784 ? R Jan30 131740:46 nginx:<br>
> worker process<br>
> root 2800 0.0 1.0 361828 165044 ? Ss Jan05 27:54 nginx:<br>
> master process /usr/sbin/nginx -g daemon on; master_process on;<br>
> <br>
> 2800 is nginx.old, also (nginx/1.15.8) as we did 2 builds with slightly<br>
> different compile options.<br>
> <br>
> The processes do not respond to nice kill signals, only a -9 was able to<br>
> kill it.<br>
<br>
So, as previously suggested, there is another problem elsewhere.<br>
<br>
And, if I'm reading "131740:46" correctly, the worker was eating <br>
CPU for about 90 days now. Looking into debugger where it spins <br>
might be helpful.<br>
<br>
Also make sure to take a look at the exact compile options (as <br>
shown by "nginx.old -V"), as well as any patches and/or modules <br>
loaded, and the configuration used.<br>
<br>
-- <br>
Maxim Dounin<br>
<a href="http://mdounin.ru/" rel="noreferrer" target="_blank">http://mdounin.ru/</a><br>
_______________________________________________<br>
nginx-devel mailing list<br>
<a href="mailto:nginx-devel@nginx.org" target="_blank">nginx-devel@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx-devel" rel="noreferrer" target="_blank">http://mailman.nginx.org/mailman/listinfo/nginx-devel</a><br>
</blockquote></div>