ValveSoftware / steam-runtime

A runtime environment for Steam applications

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

libnss_* not found if the host system relies on LD_LIBRARY_PATH to find them

smcv opened this issue · comments

Your system information

  • Steam Runtime Version: (unspecified)
  • Distribution (e.g. Ubuntu 18.04): whatever customized OS @sylware uses
  • Link to your full system information: (not provided)
  • Have you checked for system updates?: (unspecified)
  • What compatibility tool are you using?: SLR 3.0 (sniper)
  • What versions are listed in steamapps/common/SteamLinuxRuntime_sniper/VERSIONS.txt? (unspecified)

Please describe your issue in as much detail as possible:

Originally part of ValveSoftware/Dota-2#2390 (comment).

@sylware reports:

There you can see that my LD_LIBRARY_PATH is properly parsed to find libidn2... but not for the following libnss libs??

Reading between the lines, I think that perhaps the issue that @sylware meant is something like this:

  • on most Linux systems, glibc's ld.so.cache (which you can inspect with ldconfig -p) contains libnss_files.so.2, libnss_dns.so.2 and so on
  • on @sylware's system, this is not the case; instead, they set a custom LD_LIBRARY_PATH that includes a non-default directory where they have installed these core glibc libraries
  • when pressure-vessel tells libcapsule to do a soname: lookup, as it does for libidn2.so.0, it consults the DT_RUNPATH header, the LD_LIBRARY_PATH environment variable and ld.so.cache, and will work correctly
  • but when pressure-vessel tells libcapsule to do a soname-match: lookup, as it does for libnss_files.so.*, this mode of operation does not take DT_RUNPATH or LD_LIBRARY_PATH into account, only ld.so.cache
  • therefore the final container does not import the host system's libnss_files.so.2, so parsing /etc/group for textual group names does not work, which causes some sort of functional issue for ALSA dmix because it cannot find the audio group name

If that guess is correct, then there are two possible solutions:

  • on @sylware's system, use ldconfig to generate a ld.so.cache that includes all libraries that they normally want to be found by programs (as a side-effect this will also make library lookup faster and more robust)
  • and/or, in pressure-vessel, tell libcapsule to look up soname:libnss_files.so.2 and not just soname-match:libnss_files.so.* (this will make container startup somewhat slower for everyone, not just @sylware, but we won't know how significant the slowdown is until we try it)

Steps for reproducing this issue:

(None were provided)

and/or, in pressure-vessel, tell libcapsule to look up soname:libnss_files.so.2 and not just soname-match:libnss_files.so.*

I have a prototype of this, which I'll try when time permits.

It looks as though any slowdown from this is too small to measure (within measurement variation) so addressing this in pressure-vessel seems viable.

@sylware, please try replacing SteamLinuxRuntime_sniper/pressure-vessel with the result of unpacking this: https://gitlab.steamos.cloud/steamrt/steam-runtime-tools/-/jobs/378173/artifacts/raw/_build/production/pressure-vessel-bin+src.tar.gz

That should hopefully result in libnss_files.so.2 (and similar plugins) being found and loaded into the container.

tested and working:

the container alsa-lib is not able to get the audio group id and set up its IPC access right properly.

doh, I meant "is able" to get the gid of the audio group ofc.

Thx.

Thanks, the change mentioned above is in the review queue for a future release.

Fixed in today's beta updates for "Steam Linux Runtime 3.0 (sniper)" and "Steam Linux Runtime 2.0 (soldier)", versioned as 0.20231211.x. Using the beta updates is the same as using the beta branch of a game, but instead of changing the properties of the game, change the properties of the various "Steam Linux Runtime" compatibility tools instead.

The client_beta branch is normally intended to be used with the beta Steam client, but at the moment I believe it should be equally compatible with the general availability (non-beta) client.

These versions will be copied to the default (non-beta) branch when they have had more testing, most likely sometime in January.