Bug#957284: /usr/games/steam: redirects Steam stderr, games' stderr

Simon McVittie smcv at collabora.com
Fri Apr 17 12:02:09 BST 2020


Package: steam
Version: 1.0.0.47-1
Severity: normal
File: /usr/games/steam

Since 1.0.0.47-1, the Debian /usr/games/steam wrapper script redirects
steam.sh's stderr to ~/.steam/root/error.log (or in older versions
~/.steam/error.log). This was presumably intended to make debugging
easier, but it results in several issues:

- Upstream developers of Steam and games cannot give instructions to get
  extra debug information that will work on all distributions, because
  different distributions and packages send stderr to different places.

- Game and library developers are not always very consistent about where
  they send diagnostic messages. If they send some messages to stdout and
  some to stderr, those messages get separated, making debugging more
  difficult.

- Sometimes games or the Steam client have bugs that cause them to
  produce a very large amount of output, which in the worst cases
  can fill up disks. If we were writing to something like the systemd
  Journal (which is what ends up happening under at least GNOME), then
  its rate-limiting can mitigate this, but writing to a program-specific
  log file doesn't have rate-limiting available.

The upstream steam-launcher package from which this one is derived
used to log both stdout and stderr to /tmp/dumps/${USER}_stdout.txt,
but version 1.0.0.62 stopped doing this, for several reasons: it was
susceptible to symlink attacks in some kernel configurations, sometimes
filled /tmp as noted above, and according to Steam developers it was
not actually particularly useful for debugging.

As a result of the issues described above, the upstream Steam maintainers
have asked downstream distributors to stop writing Steam output to a log
file. Their intention is that the standard steps to diagnose Steam issues
will include: open a terminal (xterm or similar), run Steam from there,
and copy/paste output from the terminal. This means the wrapper script
should at least not redirect its output if its stderr is a tty.

Before changing anything about the logging, I'd like to understand why this
redirection was added. Is it there to meet a goal that is still relevant?
If so, there some other way we can meet that goal without the issues
above?

For example, on systemd systems, we could consider writing to
stdout/stderr if it's a tty, or to the Journal (by wrapping Steam with
systemd-cat or systemd-run) if not? Or the logging destination could
perhaps depend on whether Steam was run from its .desktop file or
directly, with output to stdout/stderr if run directly, but output to
the Journal or to /dev/null if run from the .desktop file?

In the longer term, I'd like to investigate whether we can use the
upstream bin_steam.sh (possibly with enhancements, modifications,
or a Debian-specific wrapper that points ~/.steam/steam to
~/.steam/debian-installation for new installations), rather than
reinventing it.

    smcv



More information about the Pkg-games-devel mailing list