Earlier quoted context omitted.
I map SIGQUIT to ^Q because that's the easiest to remember.
I suppose you never hit CTRL+S by accident?
Rarely enough that needing to open another terminal and use kill to send a signal doesn't bother me.
Beyond Ctrl-C: The dark corners of Unix signal handling
31–40 of 76 posts
Re: Beyond Ctrl-C: The dark corners of Unix signal handling
#32My 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.
> 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
Re: Beyond Ctrl-C: The dark corners of Unix signal handling
#33Earlier quoted context omitted.
> Unclean exits should be reserved for SIGQUIT (Ctrl-\) and SIGKILL (by definition). I don't know how it works on your keyboard but on french layout, Ctrl-\ is a two-hands, three-fingers, very unpleasant on the wrist, keyboard shortcut. Not a chance I'd use that for such a common operation.
The byte that sends SIGQUIT is very much configurable with stty quit ^X , but unfortunately X has to be a-z or one of \]^_ (that is, 0x41 through 0x5F except 0x5B = [ which would conflict with other uses of ESC = ^[ = 0x1B) because of how the Ctrl modifier traditionally works. Looking at a map of AZERTY, I don’t see any good options, but you may still want to experiment.
Curiously, on many terminal emulators the following work:
Ctrl-2 = Ctrl-@ = NUL byte
Ctrl-3 = Ctrl-[ = ESC
Ctrl-4 = Ctrl-\ = default for SIGQUIT
Ctrl-5 = Ctrl-] = jump to definition in vim
Ctrl-6 = Ctrl-^ = mosh escape key
Ctrl-7 = Ctrl-_ = undo in Emacs
I think these probably originate in xterm.
Re: Beyond Ctrl-C: The dark corners of Unix signal handling
#34Earlier 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
For example: Apache (httpd) replaces the 4xx and 5xx response body with its own content instead of whatever you'd returned from an external handler like wsgi. You have to use a 2xx (except for 204) to get a relevant error message back out.
Re: Beyond Ctrl-C: The dark corners of Unix signal handling
#35Earlier quoted context omitted.
> Unclean exits should be reserved for SIGQUIT (Ctrl-\) and SIGKILL (by definition). I don't know how it works on your keyboard but on french layout, Ctrl-\ is a two-hands, three-fingers, very unpleasant on the wrist, keyboard shortcut. Not a chance I'd use that for such a common operation.
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
#36Earlier 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?
For what is an error, if not a success at failing?
Re: Beyond Ctrl-C: The dark corners of Unix signal handling
#37Re: Beyond Ctrl-C: The dark corners of Unix signal handling
#38> 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…
In the Meson build system's test harness, a single Ctrl-C terminates the longest running test with a SIGTERM; while three Ctrl-C in a second interrupt the whole run as if you sent the harness a SIGTERM. This was done because it's not uncommon that there are hundreds of tests left to run and you have seen what you want, and it's useful to have an intuitive shortcut for that case.
However, in both cases it's a clean shutdown, all running are terminated and the test report is printed.
Re: Beyond Ctrl-C: The dark corners of Unix signal handling
#39Earlier quoted context omitted.
Why? That's what SIGTERM is for.
No clue what the decision making process was. There's a bug report for httpd dating back to 2011[0]. The nginx mailling list also has a grumpy person contemporary with that[1]. My guess is someone thought "httpd is a server running somewhere without a monitor attached, why on earth would it get a SIGWINCH!? surely it's available to use for something completely different", not considering users running it in the foreg…
> why on earth would it get a SIGWINCH!?
Reminds me of those "/* not reached */" stories.
Re: Beyond Ctrl-C: The dark corners of Unix signal handling
#40Earlier 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
For example: Apache (httpd) replaces the 4xx and 5xx response body with its own content instead of whatever you'd returned from an external handler like wsgi. You have to use a 2xx (except for 204) to get a relevant error message back out.
> For example: Apache (httpd) replaces the 4xx and 5xx response body with its own content instead of whatever you'd returned from an external handler like wsgi.
This is the default behavior. Apache httpd can be configured to produce different responses by way of ErrorDocument[0]. From the documentation:
Customized error responses can be defined for any HTTP
status code designated as an error condition - that is,
any 4xx or 5xx status.