Regression: some titles designed for Steam Linux Runtime 3.0 are running under SLR 1.0 instead

[smcv]

Your system information

• Steam client version (build number or date): 1731112063
• Distribution (e.g. Ubuntu): Ubuntu 24.04
• Opted into Steam client beta?: Yes
• Have you checked for system updates?: Yes
• Steam Logs: see below
• GPU: Nvidia, proprietary driver 550.120

Please describe your issue in as much detail as possible:

Some (all?) titles that have been flagged by their developer/publisher to be run under the Steam Linux Runtime 3.0 (sniper) container runtime are actually getting run under the Steam Linux Runtime 1.0 (scout) container runtime.

This happens to work OK for the first two games I tested, but is likely to cause crashes or weird regressions in some titles that were compiled in the SLR 3.0 SDK and genuinely do need the newer runtime: SLR 3.0 uses core libraries from Debian 11, but SLR 1.0 uses core libraries from Debian 10, which is 2 years older.

I suspect that this is related to the change that forces use of the SLR 1.0 (scout) container runtime for titles that previously used the legacy LD_LIBRARY_PATH-based scout runtime. Perhaps that change is unintentionally forcing use of the SLR 1.0 container runtime for all native Linux titles, even if they were designed for SLR 3.0?

Steps for reproducing this issue

1. Have a title that is intended to run under Steam Linux Runtime 3.0 (sniper). I tried:
   • Retroarch: has this issue
   • Endless Sky: has this issue
   • I could not reproduce this issue with CS2
2. Properties → Launch Options → set to empty
3. Properties → Compatibility → "Force the use of..." is unchecked
4. Launch the game
5. Look in ~/.steam/steam/logs/console.log to see exactly what we ran

Expected result

The game is running under Steam Linux Runtime 3.0 (sniper), with a command-line that in my case should look something like this:

/bin/sh\0-c\0
/home/desktop/steam-client-beta/ubuntu12_32/steam-launch-wrapper --
/home/desktop/steam-client-beta/ubuntu12_32/reaper SteamLaunch AppId=404410 --
'/home/desktop/SteamLibrary/steamapps/common/SteamLinuxRuntime_sniper'/_v2-entry-point --verb=waitforexitandrun --
'/home/desktop/SteamLibrary/steamapps/common/Endless Sky/endless-sky'\0^M

(Key facts: it's using the steamapps/common/SteamLinuxRuntime_sniper entry point script, and is not using steamapps/common/SteamLinuxRuntime/scout-on-soldier-entry-point-v2)

Actual result

The game is running under Steam Linux Runtime 1.0 (scout), with a command-line that looks something like this (lines broken for clarity, in the real log it is one very long line):

[2024-11-11 12:05:45] /bin/sh\0-c\0
/home/desktop/steam-client-beta/ubuntu12_32/steam-launch-wrapper --
/home/desktop/steam-client-beta/ubuntu12_32/reaper SteamLaunch AppId=404410 --
'/home/desktop/SteamLibrary/steamapps/common/SteamLinuxRuntime_soldier'/_v2-entry-point --verb=waitforexitandrun --
'/home/desktop/SteamLibrary/steamapps/common/SteamLinuxRuntime'/scout-on-soldier-entry-point-v2 --
'/home/desktop/SteamLibrary/steamapps/common/Endless Sky/endless-sky'\0^M

(Key facts: it's using the steamapps/common/SteamLinuxRuntime_soldier entry point script - not sniper as intended - and it is using steamapps/common/SteamLinuxRuntime/scout-on-soldier-entry-point-v2)

Workaround

Run Steam as:

steam -compat-force-slr off

Logs

In these logs, I ran Steam with no special command-line options (as steam), launched Endless Sky at 12:05, and saw that it ran in the incorrect environment.

Then I completely exited from Steam, ran Steam as steam -compat-force-slr off, re-launched Endless Sky at 12:10, and saw that it ran in the correct environment (the workaround was successful).

steam-logs.tar.gz

[smcv]

@TTimo, @kisak-valve ^ it's likely that this will indirectly trigger weird regressions for games that are meant to use SLR 3.0, so please bear that in mind when triaging: if a game is intended to run under SLR 3.0, it's worth checking that it is actually running under SLR 3.0 before investigating in more detail.

[smcv]

I cannot reproduce this for Counter-Strike 2, which still correctly runs under sniper. Perhaps this indicates that CS2 and Endless Sky/Retroarch were configured differently...

In my steam/logs/compat_log.txt, I can see that app ID 730 (CS2) has been mapped to SteamLinuxRuntime_sniper with priority 85, and SteamLinuxRuntime_sniper (again) with priority 100. Since my last Steam restart, lines relevant to 730 are:

[2024-11-11 14:43:54] Requesting mapping AppID 730 from appinfo to tool "SteamLinuxRuntime_sniper"
[2024-11-11 14:43:54] Recording non-user mapping for 730 at priority 85 to tool SteamLinuxRuntime_sniper
[2024-11-11 14:43:54] Mapping AppID 730 to tool "SteamLinuxRuntime_sniper" with priority 85
...
[2024-11-11 14:43:54] Recording non-user mapping for 730 at priority 100 to tool SteamLinuxRuntime_sniper
[2024-11-11 14:43:54] Unmapping AppID 730
[2024-11-11 14:43:54] Mapping AppID 730 to tool "SteamLinuxRuntime_sniper" with priority 100

This looks correct. We have two configurations, at priority 85 (from CS2's own configuration?) and 100 (from the SteamPlay 2.0 manifests?), and we take the higher-priority one: and it doesn't actually matter which one we take, because they are both right. The situation for Dota 2 (570) looks very similar to CS2's.

Meanwhile Retroarch, App ID 1118310, has been mapped like this:

[2024-11-11 14:43:54] Requesting mapping AppID 1118310 from appinfo to tool "SteamLinuxRuntime_sniper"
[2024-11-11 14:43:54] Recording non-user mapping for 1118310 at priority 85 to tool SteamLinuxRuntime_sniper
[2024-11-11 14:43:54] Mapping AppID 1118310 to tool "SteamLinuxRuntime_sniper" with priority 85
...
[2024-11-11 14:43:54] Recording non-user mapping for 1118310 at priority 85 to tool native
[2024-11-11 14:43:54] Unmapping AppID 1118310
[2024-11-11 14:43:54] Mapping AppID 1118310 to tool "native" with priority 85

where native is configured as an alias for SLR 1.0, I think. So we seem to have two contradictory configurations for Retroarch, with equal priority: the one "from appinfo" (from Retroarch's own configuration?) is right, the default (?) is wrong, but unfortunately their priority is equal, so it is unspecified which one wins. The situation for Endless Sky (404410) looks very similar to Retroarch's.

Team Fortress 2 has a slightly different configuration. Like Endless Sky and Retroach, it is not mentioned in the SteamPlay 2.0 manifests, but unlike Endless Sky and Retroarch, its per-app configuration has an explicit priority, 101, and this seems to result in it not being affected by Steam's new default:

[2024-11-11 14:43:54] Requesting mapping AppID 440 from appinfo to tool "SteamLinuxRuntime_sniper"
[2024-11-11 14:43:54] Recording non-user mapping for 440 at priority 101 to tool SteamLinuxRuntime_sniper
[2024-11-11 14:43:54] Mapping AppID 440 to tool "SteamLinuxRuntime_sniper" with priority 101

I think the rule that says "native Linux games run under SLR 1.0" needs to be given a lower priority than 85, so that it won't "win" vs. games' own per-title configuration saying they should run under SLR 3.0.

[smcv]

We think we know why this is happening, a potential fix is queued.

[smcv]

On desktop, this seems to be fixed in beta 1731377496 (November 11).

There was a Steam Deck beta the same day with "Fixed native titles occasionally running in the wrong runtime" in its release notes - that sounds like this fix.

[smcv]

This regression was not necessarily completely deterministic: depending on the order in which the Steam client reads or re-reads various sources of configuration, either of the two information sources that had priority 85 could "win". If the per-app configuration wins, affected games correctly run under SLR 3.0. If the default to SLR 1.0 wins, they incorrectly run under SLR 1.0.

I think the rule that says "native Linux games run under SLR 1.0" needs to be given a lower priority than 85, so that it won't "win" vs. games' own per-title configuration saying they should run under SLR 3.0.

The change that was made in the November 11 betas to solve this appears to have been to lower the priority of "native Linux games run under SLR 1.0" to 75, so that games' own per-title configuration at priority 85 will correctly take precedence in a deterministic way.

The priorities are now: default to SLR 1.0 (75) < per-title configuration (85) < SteamPlay manifests (100) < user configuration (250); those hopefully make the right thing happen in all cases.

[smcv]

The change that was made in the November 11 betas to solve this appears to have been to lower the priority of "native Linux games run under SLR 1.0" to 75, so that games' own per-title configuration at priority 85 will correctly take precedence in a deterministic way.

I believe this fix was copied into the general-availability client on November 12, https://store.steampowered.com/news/app/593110/view/4480613067569233923