Live data from Hacker News

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

sunshowers.io

11–20 of 76 posts

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

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

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

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

#12
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…

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

I think the point is that it is not to be a common operation.

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

#13
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…

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

[deleted]

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

#14
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…

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

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

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

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

#16
post #10

Earlier 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).

stty quit ^] ?

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

#17

Earlier 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.

I map SIGQUIT to ^Q because that's the easiest to remember.

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

#18
post #12

Earlier 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.

I think the point is that it is not to be a common operation.

well I don't know, it feels like I must mash ctrl-c twenty times per day on average at least

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

#19
post #3

I recently wrote a little data transfer service in python that runs in ECS. When developing it locally it was easy to handle SIGINT: try write a batch, except KeyboardInterrupt, if caught mark the transfer as incomplete and finally commit the change and shut down. But there’s no exception in python to catch for a SIGTERM, which is what ECS and other service mangers send when it’s time to shut down. So I had to add a…

  from signal import SIGTERM, raise_signal, signal
  import sys # for excepthook
  class Terminate(BaseException):
      pass
  def _excepthook(type, value, traceback):
      if not issubclass(type, Terminate):
          return _prevhook(type, value, traceback)
      # If a Terminate went unhandled, make sure we are killed
      # by SIGTERM as far as wait(2) and friends are concerned.
      signal(SIGTERM, _prevterm)
      raise_signal(SIGTERM)
  _prevhook, sys.excepthook = sys.excepthook, _excepthook
  def terminate(signo=SIGTERM, frame=None):
      signal(SIGTERM, _prevterm)
      raise Terminate
  _prevterm = signal(SIGTERM, terminate)

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

#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.
Post reply on HN