tarantool / tarantool / 28471012074

88%

Build Type

push

github

Committed by locker

Commit Message

Do not use pthread_atfork to reset signals

When Tarantool is forked, its signal configuration is reset using the
signal_reset() callback installed with pthread_atfork(). This leads
to an assertion failure on CentOS 7 based systems when application
threads are configured:

```
./tarantool/src/lib/core/fiber.c:2338: fiber_signal_reset: Assertion `cord_is_main()' failed.
```

The problem is that the built-in metrics.tarantool.memory Lua module
calls io.popen() on load, which executes pthread_atfork() handlers on
older glibc versions, the details are below, but first let's dive into
the history of signal_reset().

Its initial intention was to make the checkpoint process interruptible
back when checkpointing was done using fork(), see commit d6572f074a899
("A fix for https://bugs.launchpad.net/tarantool/+bug/992171"). Now, it
doesn't make sense because we do checkpointing in a separate thread
using our own CoW mechanism so do we really need to reset signals?

We fork the Tarantool process in the following scenarios:

 1. To daemonize the process when run in the background mode, see
    daemonize(). Here we call fork() directly.
 2. To start a logger process, see log_pipe_init(). Here fork() is
    followed by execv().
 3. To start a user-defined command with our implementation of popen().
    Here we use vfork() + execve().
 4. Tarantool can also be forked by the built-in Lua functions
    os.execute() and io.popen().

Calling signal_reset() in scenario no.1 is obviously pointless because
we don't want to reset signal handlers in this case and have to cancel
its effect with signal_init().

To figure out if we need to call signal_reset() in scenario no.2, let's
recap what signal_reset() actually does:

 1. Resets all custom signal handlers to defaults with sigaction().
 2. Unsets the interval timer used to update the low-resolution
    monotonic clock with setitimer().
 3. Unblocks all signals with pthread_sigmask().

Action no.1 is useless because custom ... (continued)

Coverage Stats

70868 of 119070 branches covered (59.52%)

0 of 1 new or added line in 1 file covered. (0.0%)

39 existing lines in 17 files now uncovered.

106434 of 121348 relevant lines covered (87.71%)

1362987.98 hits per line