I'm not sure if what follows is an issue with gunicorn, Terminator, both, or neither. I run Debian (8), I use Terminator to split up my shells, I run web apps with gunicorn. Pretty straightforward.
While resizing any of the terminals adjacent to that which is running gunicorn, for every movement event tracked, the two lines below are printed and multiple cores of my cpu (i7 4712) are pegged at 100% (or close), until I kill off gunicorn and start it up again.
[2016-05-17 16:09:55 -0400]  [INFO] Handling signal: winch
[2016-05-17 16:09:55 -0400]  [DEBUG] SIGWINCH ignored. Not daemonized
Clearly this is running in the foreground while debugging things. This behavior is not present if the terminal size remains unchanged. Not a big issue, just an annoyance.
@w-p only these 2 lines once or it appears more often?
The lines are repeated for every row / col change (SIGWINCH) to the terminal. In other words, while dragging the resize handle of the terminal window, lines are output. When not resizing, the lines do not continue - but elevated CPU usage does.
It would be really interesting to know if there is a commit that introduced that we can find via bisect. It's possible we're not clearing some state due to some kind of race or something.
I experience the same reproducable behaviour.
I’m running Django 1.9.6 with Python 3.4.3 and gunicorn 19.5.0 in a virtualenv behind nginx on Ubuntu 14.04 (DigitalOcean).
As soon as I resize my “screen” terminal (by splitting, the :resize command, or just by re-attaching to the session from another terminal) the workers’s load goes up to 25 %CPU each. Permanently. The system load avg approaches n.00 (n being the number of workers).
After sending SIGHUP (booting new workers) evrything calms down.
I can reproduce it as well. Working on it :)
@tilgovi so b0c0333 introduced the issue.
When you receive a SIGCHLD, it signal.set_wakeup_fd continuously write on the pipe and always wake up the worker. Which triggers the CPU spike. Maybe an issue in Python 3.5 ? cc @berkerpeksag
Anyway trying to find a proper fix.
make sure to remove the signal from the worker pipe
The signal was never removed from the pie which was always waking up the worker
triggering a CPU spike.
@berkerpeksag actually nevermind. My bad I was not reading the signal bit written in the pipe. fixed now.