Question: Using the Steam Runtime through SteamCMD?

[Spirrwell]

So, we have a dedicated server appid for a Source based game. Usually when people setup servers, they're installing the dedicated server through SteamCMD.

At the moment, we build with the Scout container and just kinda hope that the server runs even though when installing with SteamCMD, there is no Steam Runtime for it to run in. (A dependency on curl also makes this tremendously more painful)

I want to know if there's a proper solution to this. At the moment, we just kind of ship some of Scout's binaries (like for curl) and append their location to the LD_LIBRARY_PATH.

I would like to upgrade to the Sniper runtime at some point which is why this is important. We would need to somehow be able to run the dedicated server in the Sniper runtime. The last time I tried to build with a newer runtime, we had complaints from server owners because of the newer GLIBC. So, I would really like to be able to properly run this in the runtime.

Any information is greatly appreciated.

(As a side note, if we do upgrade to Sniper, the docs say to contact Valve as there is no method to set the Sniper runtime as the default for the game. Is this still the case?)

[smcv]

scout

At the moment, we build with the Scout container and just kinda hope that the server runs even though when installing with SteamCMD, there is no Steam Runtime for it to run in. (A dependency on curl also makes this tremendously more painful)

There are two main ways to do this.

The first is a 1:1 equivalent of how the Steam client will normally run your game client, using the scout libraries as an overlay over whatever random host OS you or your dedicated server operators happen to be using. Download steam-runtime.tar.xz from https://repo.steampowered.com/steamrt1/images/latest-steam-client-general-availability/ or copy the version that your Steam client downloaded into ~/.steam/root/ubuntu12_32, unpack it in some convenient place, and (ask your dedicated server operators to) run it like this:

$ /path/to/steam-runtime/setup.sh
$ /path/to/steam-runtime/run.sh -- /path/to/your-game-server

The second is a "pure" and pedantically correct scout runtime (Ubuntu-12.04-based) container environment. To get this, fetch the OCI (Docker/Podman) image described in https://gitlab.steamos.cloud/steamrt/scout/platform, and (ask your dedicated server operators to) run your game inside that.

A variation of the first way would be to fetch a container image for either Debian (e.g. docker pull debian:bullseye) or the sniper runtime (see https://gitlab.steamos.cloud/steamrt/sniper/platform), and then do the first way inside that container. This would give you the predictability of a known base OS, plus full scout ABI compatibility.

[smcv]

sniper

I would like to upgrade to the Sniper runtime at some point which is why this is important. We would need to somehow be able to run the dedicated server in the Sniper runtime.

For this, the easiest way will be to use the OCI (Docker/Podman) image described in https://gitlab.steamos.cloud/steamrt/sniper/platform.

It is also possible to download and use SteamLinuxRuntime_sniper without using Steam, but SLR brings you a significant amount of complexity that is really only there to handle graphics drivers, which should be irrelevant for a dedicated server, and complexity means bugs - so I would recommend avoiding that, and using Docker or Podman instead.

[smcv]

As a side note, if we do upgrade to Sniper, the docs say to contact Valve as there is no method to set the Sniper runtime as the default for the game. Is this still the case?

To the best of my knowledge, yes that's still the case.

If there was a "self-service" mechanism to do this, it would be part of Valve's partner web interface, the same place you set other metadata for your game.

[smcv]

a "pure" and pedantically correct scout runtime (Ubuntu-12.04-based) container environment

I should mention that this option is only going to work if your game has been compiled in an equally "pure" build environment for scout: either the SDK Docker/Podman/Toolbx image described in https://gitlab.steamos.cloud/steamrt/scout/sdk (recommended since 2022), or an equivalent schroot environment (equally valid, but more annoying to get it working). I would personally recommend Toolbx and/or Podman for interactive development, and Podman or Docker for automated builds on a CI system.

If you're compiling your game in a newer environment than scout (perhaps Debian 10 or Ubuntu 16.04 or similar) then it is already a matter of luck that it's working on end-user systems, and it certainly won't run successfully in the Platform container from https://gitlab.steamos.cloud/steamrt/scout/platform, so you will need to go one of the other routes.

In the long term, you are correct to think that the way to get a newer build and runtime environment for new or actively-maintained Steam games will be to build and run them in sniper, the same way that Valve are now handling Counter-Strike 2 and Dota 2. For games that are already active/released, the way to do this is to transition a non-default beta branch first, (ask Valve to) swap that branch over to sniper, get that working to your satisfaction, and then (coordinate with Valve again to) reapply the configuration change in your default branch.

I'm hoping that configuring the runtime to be used for your game can become a self-service thing that doesn't require Valve's help, but that isn't something that I have control over.

Out of interest, which game is this? (But if you would prefer not to say in public while discussing its technical details, then I understand!)

[Spirrwell]

The game is Pirates, Vikings, and Knights II. We are using a Scout container and I do use docker/podman. I want to move to a newer runtime primarily to make developing on Linux easier. Unfortunately the GLIBC version of Scout is so old that using something like VSCode's devcontainer tools isn't really possible.

Many years ago, I did try to do a build based on a newer Ubuntu image, but some server owner running CentOS with an ancient GLIBC version could no longer run it. This was before Soldier existed I believe. So, that's why now I'm really interested in what a better option is for our dedicated servers to run them in the runtime. I don't want to break anything for server owners.

Based on everything you've said, it may be easiest for us to continue using Scout for now. I'm sure I could somehow modify our dedicated server's launch script to handle what the setup.sh and run.sh do.

Technically I guess we could use Soldier, but the docs say you can't have a game on Steam using Soldier, and thus it sounds like Valve doesn't support that.

I guess I'll just have to think some more about it. Thanks for all the information though.

[smcv]

Technically soldier (Steam Runtime 2) is exactly "the same shape" as sniper (Steam Runtime 3), just older - it's based on Debian 10 rather than sniper's Debian 11. The reason why Valve is not supporting soldier as an independent target for native Linux games is to limit the number of actively used runtimes. Each container runtime that a user installs will cost around 700M, which is perhaps no big deal on a modern desktop/laptop or the current-generation Steam Deck with 512G+ storage, but adds up quickly if your gaming platform is an old desktop/laptop or the smallest model of the first-generation Steam Deck, which only had 64G eMMC.

There wouldn't be much point in targeting soldier anyway: changing from scout to either soldier or sniper would take about the same amount of work, and if you're going to make that investment, you might as well get the benefit of libraries that are 2 years newer.

We are using a Scout container and I do use docker/podman

That's good, you're building your game in a supportable way. (Not all developers of native Linux games on Steam do, unfortunately! Thanks for being one of the supportable ones.)

Unfortunately the GLIBC version of Scout is so old that using something like VSCode's devcontainer tools isn't really possible.

Yes. For the LD_LIBRARY_PATH-based scout runtime, it's a bit of a vicious cycle: you can't have the benefits of a newer glibc while also having the benefits of an older glibc. Newer development tools and dependencies want a newer glibc, but if we upgrade it, as well as having a potential for internal regressions, we would be raising the minimum requirement to run any game that was compiled on scout, which would mean people like your CentOS user would not necessarily be able to run your game any more.

Our exit strategy from this is to use the new container runtimes like sniper (which use namespaces/containers to be able to rely on a newer glibc without imposing new minimum requirements), and recommend those as the way of the future. But that needs a metadata transition, and I don't think you can do that in a self-service way just yet.

Many years ago, I did try to do a build based on a newer Ubuntu image, but some server owner running CentOS with an ancient GLIBC version could no longer run it

Yes, unfortunately this is expected. If you built in a newer environment (whether that means soldier, sniper or Ubuntu) and then ran in Steam's traditional LD_LIBRARY_PATH-based scout environment, then it would be a matter of luck whether the resulting binaries will be runnable on any given end-user system - you'd be relying on the end-user coincidentally having particular versions of particular libraries installed. That isn't something that we can support.

In the medium to long term, the way to get out of this trap is to build and run your game in a sniper container, the same as games like Counter-Strike 2:

• At build-time, this would just mean using a sniper Docker/Podman container instead of your current scout Docker/Podman container (and possibly adjusting your build system or code to cope with sniper having newer libraries and a newer version of gcc).
• On the client side, that means changing the game's Steam metadata to flag it as "please run branch x under sniper", or eventually "please run all branches under sniper", which I think at the moment is something that only a Valve developer can do for you. If you would be interested in experimenting with that, please create a (public or private) beta branch to hold an experimental sniper-based version of your game, and we can ask Valve developers to flag that branch to run under sniper when they get back from vacation.
• On the dedicated server side, there are a couple of options:
  • As I said above, probably the easiest way would be to ask dedicated server operators to run your dedicated server in a sniper Docker/Podman container, instead of on their "real" system. I suspect they might prefer to run it in a container anyway, for better security hardening in case your dedicated server has a vulnerability, so everyone wins from this approach.
  • Or as I said above, you could ask them to do this: https://gitlab.steamos.cloud/steamrt/sniper/platform#running-the-steam-container-runtime-without-steam
  • Or technically you can download sniper with steamcmd (it's app ID 1628350 and is freely available to any Steam account) but that's essentially equivalent to downloading it from https://repo.steampowered.com/steamrt-images-sniper/snapshots/, so you'd still need to ask dedicated server operators to run it as something like /path/to/SteamLinuxRuntime_sniper/run -- ./my-server

[smcv]

Is https://steamcommunity.com/app/17570/discussions/0/1698300679775227577/ your official guide for running PVK2 dedicated servers?

I think it might be useful to have a template for a "how to run a dedicated server" guide for scout games, and the same for sniper games. PVK2 is free, so it seems like that could be a good game to use as an example.