Window resizing vs. Gunicorn

Weirdest behavior I’ve seen in a Unix server in the longest time. Here’s what happens when I’m running a GUnicorn server (with Tilestache) and resize the iTerm2 it’s attached to.

2013-05-13 18:59:20 [7941] [INFO] Handling signal: winch
2013-05-13 18:59:20 [7941] [INFO] graceful stop of workers
2013-05-13 18:59:20 [7944] [INFO] Worker exiting (pid: 7944)
INFO:gunicorn.error:Worker exiting (pid: 7944)

I thought this was some sort of sick joke, but it’s for real. GUnicorn interprets SIGWINCH to mean “gracefully stops workers but keep the master running“. Which is absolutely terrible in an interactive environment where I might deliberately resize a window while debugging. Particularly with tabbed terminal windows. UI actions in the controlling terminal = kill server, how intuitive!

I can’t even figure out when I’d actually want the documented behavior. The workers don’t restart; is there some way to manually start them? What’s left in a GUnicorn server after you shut down the workers?

Update: this was fixed in GUnicorn, see issue 500. SIGWINCH now only shuts stuff down if in daemon mode. Which seems reasonably safe. Still seems an odd choice of signal to me, but I see there’s precedent with Nginx and maybe they were running out of signals.

2 thoughts on “Window resizing vs. Gunicorn

  1. This blog is quite misunderstanding what happen when Gunicorn is receiving a SIGWINCH. In daemon mode, any change in the window size should be interpreted as a change that could impact the daemon, this is why it is stopping all the workers. However, when Gunicorn run interactively, this isn’t a problem and only a warning is displayed.

    The patch referenced in 500 make sure that gunicorn can be used inside a shell script and fix the way we are checking when Gunicorn run in daemon mode.

  2. Thank you, yes, I hadn’t realized it was only supposed to happen in daemon mode. This SIGWINCH behavior isn’t a problem after the patch from issue 500. Still curious why SIGWINCH is used for daemons; is it because it’s a signal that’s otherwise unused, or is it something special about when a daemon might get a SIGWINCH?

Comments are closed.