Fix SIGHUP/SIGCONT sometimes reaching the child due to tty quirks

[chriskuehl]

Fixes #136

To summarize, the issue in #136 is that when dumb-init calls TIOCNOTTY, the kernel will send a SIGHUP and SIGCONT to the dumb-init process if dumb-init is the session leader. Quoth man tty:

    TIOCNOTTY
       Detach the calling process from its controlling terminal.

       If the process is the session leader, then SIGHUP and  SIGCONT  signals
       are  sent to the foreground process group and all processes in the cur‐
       rent session lose their controlling tty.

When this happens, there's a race with two possible outcomes:

1. (Happy path) dumb-init pid1 receives the SIGHUP/SIGCONT and forward them to the child (pid2), but the child hasn't yet exec'd the real process. The pid2 dumb-init just ignores the signals, eventually execs the real process, and nobody notices this quirk.
2. (Sad path) dumb-init pid2 has exec'd the real process by the time the pid1 dumb-init forwards it the SIGHUP/SIGCONT. The real process gets the SIGHUP and usually dies with status code 129 (killed by SIGHUP).

Typically (1) happens, but some environments cause (2) to happen more frequently, probably due to differences in how the scheduler behaves.

This is a fairly non-intrusive fix: it just ignores the first SIGHUP/SIGCONT. At some point I'd still like to see if there's a better fix (can we hand the session to the child when we're the session leader rather than creating a new one?), but this should be fairly safe.

Still working on writing a test. Unfortunately it's hard to test the actual functionality (hard to force the race without patching dumb-init's code) so it may end up just asserting debug messages :(

[asottile]

👍 idea seems good. We talked through some of the scenarios offline including duplicate SIGHUP / SIGCONT signals -- the nice thing is that just eating one of these signals is fine as the kernel / user signals here are indistinguishable (kernel / user send SIGHUP during fork, dumb-init eats one and forwards the other).

[chriskuehl]

Should be ready for final review / merge now. Seems like the ppc64le tests are failing though, and not producing a log, so I wonder if something is wrong with the Travis ppc64le infrastructure? :(

@ghatwala any idea why we'd be seeing that with the PPC tests?

[asottile]

otherwise looks good!

[asottile]

maybe Ignoring tty hand-off signal... so it's more clear why this is happening here

[chriskuehl]

I like this wording better, changed to that.