Live data from Hacker News

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

sunshowers.io

61–70 of 76 posts

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

#61
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.

definitely laugh! life's too short, you'll never get out alive :)

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

#63
post #22
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.

y'know...what really is an error, anyway?

In my day, successful commands output nothing at all, so it would seem that a blank page is the only truly error-free result.

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

#64

The article doesn't mention the most useful of all signals: SIGINFO, aka "please print to stderr your current status". Very useful for tools like dd and tar. Probably because Linux doesn't implement it. Worst mistake Linus ever made. Also, it talks about self-pipe but doesn't mention that self- socket is much better since you can't select on a pipe.

SIGSTOP and SIGCONT are very useful as well.

SIGSTOP is the equivalent of Ctrl-Z in a shell, but you can address it to any process. If you have a server being bogged down, you can stop the offending process temporarily.

SIGCONT undoes SIGSTOP.

The cpulimit tool does this in an automated way so that a process can be limited to use x% of CPU. Nice/renice doesn't keep your CPU from hitting 100% even with an idle priority process, which may be undesirable if it drains battery quickly or makes the cooling fan loud.

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

#65
post #35
post #10

Earlier quoted context omitted.

While on UK keyboards it's the opposite "problem" - the left Ctrl key and the \ key are right next to each other (making it potentially a one-finger operation), which is the opposite of how a US keyboard is laid out (where Ctrl-\ was presumably intended to need to be a two-handed, two-finger operation).

> which is the opposite of how a US keyboard is laid out (where Ctrl-\ was presumably intended to need to be a two-handed, two-finger operation). We have a right Ctrl, so one-hand two-finger.

When using a keyboard "properly" how are you gonna manage that?

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

#66
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

If you’re using HTTP for something other than transferring hypertext — i.e., if your application is not a hypermedia application — then you are doing something just as wrong as encoding IP in DNS packets or email messages. Don’t do that. It’s wrong, even if it is technically interesting.

If, OTOH, your application is a hypermedia application, then returning a success status for errors is just wrong.

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

#67
post #66

Earlier quoted context omitted.

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

If you’re using HTTP for something other than transferring hypertext — i.e., if your application is not a hypermedia application — then you are doing something just as wrong as encoding IP in DNS packets or email messages. Don’t do that. It’s wrong, even if it is technically interesting. If, OTOH, your application is a hypermedia application, then returning a success status for errors is just wrong.

Every JSON API under the sun disagrees, but I do agree in principle. People very much like using HTTP as a JSON (or XML) transfer protocol

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

#68
post #66

Earlier quoted context omitted.

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

If you’re using HTTP for something other than transferring hypertext — i.e., if your application is not a hypermedia application — then you are doing something just as wrong as encoding IP in DNS packets or email messages. Don’t do that. It’s wrong, even if it is technically interesting. If, OTOH, your application is a hypermedia application, then returning a success status for errors is just wrong.

Sorry, what? HTTP is perfectly fine for APIs which are not hypermedia.

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

#69
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.

That's ... not what most people are doing. People send _application_ errors on HTTP 200 response codes, because HTTP response codes are for HTTP and not applications. Most "REST" libraries and webdev get this wrong, building ever more fragile web services.

Task failed successfully

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

#70
post #59
post #10

Earlier quoted context omitted.

While on UK keyboards it's the opposite "problem" - the left Ctrl key and the \ key are right next to each other (making it potentially a one-finger operation), which is the opposite of how a US keyboard is laid out (where Ctrl-\ was presumably intended to need to be a two-handed, two-finger operation).

two handed operations shouldn't exist.

I completely agree - they're very inaccessible. That's why I quoted the word "problem"; it's not actually a problem at all.
Post reply on HN