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.
Beyond Ctrl-C: The dark corners of Unix signal handling
61–70 of 76 posts
Re: Beyond Ctrl-C: The dark corners of Unix signal handling
#62Re: Beyond Ctrl-C: The dark corners of Unix signal handling
#63Earlier 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?
Re: Beyond Ctrl-C: The dark corners of Unix signal handling
#64The 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 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
#65Earlier 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.
Re: Beyond Ctrl-C: The dark corners of Unix signal handling
#66Earlier 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, 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
#67Earlier 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.
Re: Beyond Ctrl-C: The dark corners of Unix signal handling
#68Earlier 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.
Re: Beyond Ctrl-C: The dark corners of Unix signal handling
#69Earlier 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.
Re: Beyond Ctrl-C: The dark corners of Unix signal handling
#70Earlier 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.