Skip to content
Snippets Groups Projects
  • Simon McVittie's avatar
    be4aae8d
    Unblock signals when spawning subprocesses, and in s-r-s-i · be4aae8d
    Simon McVittie authored
    
    This avoids a coreutils limitation in versions [8.27, 8.29), which
    unfortunately includes Ubuntu 18.04: timeout(1) relied on SIGCHLD not
    being blocked, but did not unblock it themselves.
    
    The Steam client runs s-r-s-i from a thread that has SIGCHLD blocked,
    and SIGALRM, SIGPIPE and SIGTRAP ignored. This is contrary to frequent
    expectations of general-purpose libraries and command-line utilities:
    in particular, SIGPIPE is used by processes writing to a pipe to detect
    that the read end has died, SIGTRAP is frequently used to terminate
    processes on an assertion failure, and SIGCHLD is often necessary for
    subprocess management.
    
    Games (whether Steam or non-Steam) appear to be run with only SIGPIPE
    and SIGTRAP ignored, so strictly speaking, unignoring those two makes
    the behaviour of s-r-s-i unlike the behaviour of actual games. However,
    the effect of unblocking SIGPIPE and SIGTRAP is to make s-r-s-i more
    likely to crash (the default disposition of both those signals is process
    termination), which is probably what we want: if there is any difference,
    we want s-r-s-i's helpers to be more strict than games (crash more often),
    so that they can act as an early-warning system for issues that could
    manifest in games.
    
    In s-r-s-i, don't unblock signals until after we have finished
    command-line parsing and redirected stdout to print to the original
    stderr. Otherwise, g_debug() would go to the original stdout, resulting
    in it being invalid JSON.
    
    Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
    be4aae8d
    History
    Unblock signals when spawning subprocesses, and in s-r-s-i
    Simon McVittie authored
    
    This avoids a coreutils limitation in versions [8.27, 8.29), which
    unfortunately includes Ubuntu 18.04: timeout(1) relied on SIGCHLD not
    being blocked, but did not unblock it themselves.
    
    The Steam client runs s-r-s-i from a thread that has SIGCHLD blocked,
    and SIGALRM, SIGPIPE and SIGTRAP ignored. This is contrary to frequent
    expectations of general-purpose libraries and command-line utilities:
    in particular, SIGPIPE is used by processes writing to a pipe to detect
    that the read end has died, SIGTRAP is frequently used to terminate
    processes on an assertion failure, and SIGCHLD is often necessary for
    subprocess management.
    
    Games (whether Steam or non-Steam) appear to be run with only SIGPIPE
    and SIGTRAP ignored, so strictly speaking, unignoring those two makes
    the behaviour of s-r-s-i unlike the behaviour of actual games. However,
    the effect of unblocking SIGPIPE and SIGTRAP is to make s-r-s-i more
    likely to crash (the default disposition of both those signals is process
    termination), which is probably what we want: if there is any difference,
    we want s-r-s-i's helpers to be more strict than games (crash more often),
    so that they can act as an early-warning system for issues that could
    manifest in games.
    
    In s-r-s-i, don't unblock signals until after we have finished
    command-line parsing and redirected stdout to print to the original
    stderr. Otherwise, g_debug() would go to the original stdout, resulting
    in it being invalid JSON.
    
    Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>