Live data from Hacker News

Beyond Ctrl-C: The dark corners of Unix signal handling

sunshowers.io

41–50 of 76 posts

Re: Beyond Ctrl-C: The dark corners of Unix signal handling

#41
post #20
post #2

My favorite signal surprise was running nginx and/or httpd in the foreground and wondering why on earth it quit whenver i resized the window. Turns out, they use SIGWINCH (which is sent on WINdow CHange) for graceful shutdown. It's a silly, silly problem.

Why? That's what SIGTERM is for.

They use SIGWINCH for gracefully shutting down workers but not the main process [0]. SIGQUIT is used for a graceful shutdown and SIGTERM for a sort of graceful shutdown (with timeouts).

SIGWINCH is apparently used for an online upgrade [1]. Because it only shuts the workers down you can quickly transition back to the old binary and old configuration if there's a problem, even after upgrading the binary or config stored on the hard drive.

I'm sure there are other ways to get a similar capability, but this set of signals is apparently what they came up with.

[0] http://nginx.org/en/docs/dev/development_guide.html#processe...

[1] https://www.digitalocean.com/community/tutorials/how-to-upgr...

Re: Beyond Ctrl-C: The dark corners of Unix signal handling

#43
post #2

My favorite signal surprise was running nginx and/or httpd in the foreground and wondering why on earth it quit whenver i resized the window. Turns out, they use SIGWINCH (which is sent on WINdow CHange) for graceful shutdown. It's a silly, silly problem.

I don't know whether to laugh or cry.

Re: Beyond Ctrl-C: The dark corners of Unix signal handling

#44
post #6
post #4

> Another common extension is to use what is sometimes called a double Ctrl-C pattern. The first time the user hits Ctrl-C, you attempt to shut down the database cleanly, but the second time you encounter it, you give up and exit immediately. This is a terrible behavior, because users tend to hit Ctrl-C multiple times without intending anything different than on a single hit (not to mention bouncing key mechanics and…

If you don't know about it, sure, but I find it's kind of convenient to get a safe shutdown and then be able to easily say "I don't care, just stop this program" without needing a separate kill -9 command or something.

[deleted]

Re: Beyond Ctrl-C: The dark corners of Unix signal handling

#45
post #7
post #6

Earlier quoted context omitted.

If you don't know about it, sure, but I find it's kind of convenient to get a safe shutdown and then be able to easily say "I don't care, just stop this program" without needing a separate kill -9 command or something.

As I wrote, Ctrl-\ should do the trick. And it’s just not practical having to know which program applies the double pattern, and having to train yourself to not accidentally hit Ctrl-C twice.

My brush with the double-ctrl-C pattern was in a place that wrote a lot of Java. It was generally frowned on to write any code that relied on signals which windows users can't send, and if I recall, Java made it quite difficult anyhow.

Windows does have a tradition of using ctrl-c to quit though, so SIGINT ends up being one of the few that you can use in both places. It's not pretty, but giving it a different meaning based on how many times you've ordered it seems like a somewhat natural next step, if a hacky one.

Re: Beyond Ctrl-C: The dark corners of Unix signal handling

#47
post #4

> Another common extension is to use what is sometimes called a double Ctrl-C pattern. The first time the user hits Ctrl-C, you attempt to shut down the database cleanly, but the second time you encounter it, you give up and exit immediately. This is a terrible behavior, because users tend to hit Ctrl-C multiple times without intending anything different than on a single hit (not to mention bouncing key mechanics and…

It's worse, because there are languages that encode interruption into the error handling functionality, so it's common that people mismanage their errors and programs require several Ctrl-C presses to actually reach the interruption handler.

What means that you have to memorize a list of "oh, this program needs Ctrl-C 3 times; oh, this program must only receive Ctrl-C once!"... I don't know of any "oh, this program needs Ctrl-C exactly 2 times", but it's an annoying possibility.

Re: Beyond Ctrl-C: The dark corners of Unix signal handling

#48
post #37

Earlier quoted context omitted.

I suppose you never hit CTRL+S by accident?

stty -ixon Make sure that thing is disabled

I like that Konlose defaults into disabling that thing. And also that there is a visual sign of the terminal being stopped.

Re: Beyond Ctrl-C: The dark corners of Unix signal handling

#49
post #4

> Another common extension is to use what is sometimes called a double Ctrl-C pattern. The first time the user hits Ctrl-C, you attempt to shut down the database cleanly, but the second time you encounter it, you give up and exit immediately. This is a terrible behavior, because users tend to hit Ctrl-C multiple times without intending anything different than on a single hit (not to mention bouncing key mechanics and…

It's worse, because there are languages that encode interruption into the error handling functionality, so it's common that people mismanage their errors and programs require several Ctrl-C presses to actually reach the interruption handler. What means that you have to memorize a list of "oh, this program needs Ctrl-C 3 times; oh, this program must only receive Ctrl-C once!"... I don't know of any "oh, this program n…

Any software I've come across that uses intentional double ctrl-c shows a message after the first ctrl-c. Something to the effect of "shutting down gracefully, press ctrl-c again for immediate shutdown".

Hence you can just press it once and wait half a second, if no message to this effect appears you can spam ctrl-c.

Re: Beyond Ctrl-C: The dark corners of Unix signal handling

#50
post #11

Earlier quoted context omitted.

> Turns out, they use SIGWINCH (which is sent on WINdow CHange) for graceful shutdown. That’s … that’s even worse than people who send errors with an HTTP 200 response code.

Disagree. Annoyingly there is a reasonable case for 200 but with an error, if http is your transport but not your application, then 200 says "yes, the message was transfered and understood correctly, here is your response" which may be an error response from the application

Which is why "you resized the terminal window, clearly you meant to shut down this web server" is even crazier, yes
Post reply on HN