Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

sunshowers.io

Post reply on HN
Print view View original

21–30 of 76 posts

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

#21

Post by chrsig »

thayne wrote: post #20
chrsig wrote: 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.

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 foreground during development. Nginx probably followed suit for convention, but that's pure speculation on my part.

Also that was before docker really took off (I'm not sure if it was around in 2011 yet; still in it's infancy maybe). Running it in the foreground didn't happen as much yet. People were still using wamp or installing it via apt and restarting via sudo.

[0] https://bz.apache.org/bugzilla/show_bug.cgi?id=50669

[1] https://mailman.nginx.org/pipermail/nginx/2011-August/028640...

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

#22

Post by chrsig »

eadmund wrote: post #11
chrsig wrote: 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.

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

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

#23

Post by fragmede »

cperciva wrote: post #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.

dd prints out status when sent SIGUSR1, but yeah that would be cool if other utilities did that as well off SIGINFO.

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

#24

Post by ibash »

thayne wrote: post #20
chrsig wrote: 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.

I tried to find out why.

Unfortunately the change that introduces it predates the official release by a few months. And predates the mailing list by about a year:

https://trac.nginx.org/nginx/changeset/5238e93961a189c13eeff...

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

#25

Post by cperciva »

fragmede wrote: post #23
cperciva wrote: post #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.

dd prints out status when sent SIGUSR1, but yeah that would be cool if other utilities did that as well off SIGINFO.

And does ^T map to SIGUSR1? That's the other thing which makes it so useful in BSD.

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

#26

Post by chrsig »

ibash wrote: post #24
thayne wrote: post #20

Earlier quoted context omitted.

Why? That's what SIGTERM is for.

I tried to find out why. Unfortunately the change that introduces it predates the official release by a few months. And predates the mailing list by about a year: https://trac.nginx.org/nginx/changeset/5238e93961a189c13eeff...

ok, I found a commit in 2005, coming about because linuxthreads was interfering with the SIGUSR1 signal.

It looks like they wound up making it platform specific, so BSDs and unix like operating systems might still use SIGUSR1.

https://github.com/apache/httpd/commit/395896ae8d19bbea10f82...

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

#27

Post by epcoa »

cperciva wrote: post #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.

> self-socket is much better since you can't select on a pipe.

This needs further explanation. Why can’t you select on a pipe? You certainly can use select/poll on pipes in general and I’m not sure of any reason in particular they won’t work for the self pipe notification.

Its even right in the original: https://cr.yp.to/docs/selfpipe.html

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

#28

Post by wombatpm »

tripdout wrote: post #6
layer8 wrote: 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.

Kids these day. Try resetting server windows on a sgi.

Subject: -42- How can I restart the X server? Date: 10 Sep 1995 00:00:01 EST

  To restart the X server (Xsgi) once, do any one of the following
  (in increasing order of brutality):

  - killall -TERM Xsgi
  - hold down the left-Control, left-Shift, F12 and keypad slash keys
    (this is fondly known as the "Vulcan Death Grip")
  - /usr/gfx/stopgfx; /usr/gfx/startgfx
  - reboot

  To restart the X server every time someone logs out of the console,
  edit /var/X11/xdm/xdm-config, change the setting of
  "DisplayManager._0.terminateServer" from "False" to "True" and do
  'killall -HUP xdm'.

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

#29

Post by glandium »

cperciva wrote: post #17
mananaysiempre wrote: post #14

Earlier quoted context omitted.

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.

I suppose you never hit CTRL+S by accident?

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

#30

Post by cperciva »

epcoa wrote: post #27
cperciva wrote: post #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.

> self-socket is much better since you can't select on a pipe. This needs further explanation. Why can’t you select on a pipe? You certainly can use select/poll on pipes in general and I’m not sure of any reason in particular they won’t work for the self pipe notification. Its even right in the original: https://cr.yp.to/docs/selfpipe.html

Oops, brainfart. Sadly it's too late for me to edit that comment.

Yes, you can select just fine on pipes. What I was thinking of is that recv and send doesn't work on pipes, and asynchronous I/O frameworks typically want to use send/recv rather than write/read because the latter don't have a flags parameter.

Post reply on HN