Skip to content

CLI tools: unblock and unignore signals during startup

Simon McVittie requested to merge wip/task354 into main
  • Consistently unblock and unignore signals during CLI tool startup

    As with s-r-launcher-service, Steam or a game could run these tools in an arbitrary environment, with necessary signals either blocked (sigprocmask() or similar), or ignored (sigaction() with action SIG_IGN, or similar). Both of these are inherited across fork() and execve() by default.

    s-r-system-info and s-r-check-compatibility do not need this change: they already called _srt_unblock_signals(), which unblocks all signals, and unignores selected signals that have been a practical problem in the past.

    pv-try-setlocale does not need this change: in practice it only gets run by pv-adverb, so it inherits pv-adverb's fix for this.

    helpers/ do not need this change: they get called with _srt_child_setup_unblock_signals() and inherit its fix for this.

    tests/ do not need this change: Meson should run them in a sensible environment.

    steamrt/tasks#354

  • utils: Clarify when _srt_child_setup_unblock_signals() can be called

  • utils: Log a warning if we reset a custom signal handler

    When our executables get run via execve(), any custom signal handlers get reset to SIG_DFL by the kernel: nothing else would make sense, because the pointer to a custom signal handler would no longer be valid in the new executable's address space. As a result, we start up with all signals set to either SIG_IGN or SIG_DFL.

    _srt_unblock_signals() is meant to be called sufficiently early that it will not reset any custom signal handlers, because there should not yet be any. Log a warning if that assumption is broken.

  • utils: Unignore all signals, not just the ones Steam historically altered

    To get from an unknown execution environment into a known state, it's more robust if we reset all signals, not just a few.

  • Fix error reporting for pthread_sigmask()

    Unlike most POSIX functions, instead of returning -1 and setting errno on error, pthread_sigmask() returns a positive errno-like value on error.

  • pv-adverb, launcher-service: Use _srt_child_setup_unblock_signals

    This avoids some duplication. It does mean that we can't check for failures, but it's not as if we can really do anything useful about any error from pthread_sigmask() anyway.

    The only errors documented for pthread_sigmask() are EFAULT (a programming error) and EINVAL (either a programming error, or use of a signal-set size not supported by the kernel). If we were going to get EINVAL, we would also have had the same error during program startup, when we called _srt_unblock_signals(), which does report errors.

Edited by Simon McVittie

Merge request reports