Skip to content

Draft: pv-wrap: Optionally send the actual game's output to the systemd Journal

Simon McVittie requested to merge wip/smcv/pv-wrap-to-journal into main

This gives us a way to get all output into one place.

Based on !521 (merged), only the last commit is new here.

I've put this here so we can think about it some more, but I'm not at all sure that this is the right thing to be doing: if our caller is launching the wrapped program and expecting to read its stdout from a pipe (like Help -> System Information does), then we certainly don't want to be suppressing that output, which this branch would unfortunately be doing whenever PRESSURE_VESSEL_SYSTEMD_LOGGING is set. On the other hand, if a game is writing random unstructured diagnostics to stdout, then we probably do want a way to direct those to the Journal alongside its stderr. The difficulty here is in telling which is which!

Perhaps a better way to get games' output sent to the Journal (conditionally or unconditionally) would be to teach steamrt/steam-launch-wrapper> to set up stdout and stderr as Journal streams before exec'ing pressure-vessel. The big advantage of that approach is that it would work for any game equally, regardless of whether it's native Linux or Proton, and with either the LD_LIBRARY_PATH scout runtime or one of the SLR runtimes. With !521 (merged), this would result in pressure-vessel automatically reopening those streams to get itself labelled correctly, and then giving back the original streams for the actual game, which seems like what we want.

However, steam-launch-wrapper is currently non-GLib, and is currently built as part of the Steam client rather than as part of the scout runtime; so that would require doing one of these:

  • doing a bunch of not-invented-here in steam-launch-wrapper to reimplement the utility functions we need in terms of libc
  • giving it a GLib dependency (and backports of the parts we need for older GLib)
  • adopting it into steam-runtime-tools and teaching the Steam client build to copy its private steam-launch-wrapper executable from there
  • adopting it into steam-runtime-tools and teaching the Steam client to run the copy that's in the scout runtime (which would presumably also need a fallback to skipping the wrapper for the unsupported STEAM_RUNTIME=0 case)

The second and third of those options would require LGPL compliance (corresponding source code release for what is currently just shipped as a binary), and the first would either require LGPL compliance or a permissively-licensed independent reimplementation of the same ideas.

Alternatively, perhaps we could ignore PRESSURE_VESSEL_SYSTEMD_LOGGING unless SteamAppId is also set - that seems like the closest thing we have to distinguish between the actual game (SteamAppId set) and setup/ancillary commands (not set)? Or is that too much magic?

/cc @denittis

Merge request reports