tree 411bbf5a9880139a2dcf3550810dba69a91d1efc
parent 731e87e9620c629d7506396f89726bb61825fc95
author jacobsa <jacobsa@google.com> 1600853005 -0700
committer Copybara-Service <copybara-worker@google.com> 1600853065 -0700

linux-sandbox-pid1: don't try to forward signals before forking.

This causes us to forward to PID 0, i.e. to ourselves. That in turn can cause
us to get into a 100% CPU loop under certain cases.

For example, the following sequence of events:

1.  The root process (linux-sandbox.cc) spawns the child process
    (linux-sandbox-pid1.cc).

2.  The root process installs signal handlers, including a SIGTERM handler that
    forwards SIGTERM and then calls alarm(2).

3.  The root process never installs the specific SIGALRM handler, either
    because timeout_secs is not positive or because it is delayed for a very
    long time for whatever reason.

4.  bazel sends SIGTERM to the root process. This is forwarded to the child,
    which starts forwarding it to itself in a loop, because fork hasn't yet
    returned. In the root process, an alarm is installed.

5.  Eventually the alarm expires in the root process, and again it is forwarded
    to the child.

6.  The child is now forwarding both SIGTERM and SIGALRM to itself.

While I was at it, rationalized the signal forwarding behavior. SIGTERM is the
only one that seems to make sense to forward; even SIGALRM doesn't make sense
because we don't ask the kernel to give it to us in the first place, so we
never expect to receive it.

PiperOrigin-RevId: 333252396