steamclient.so: cannot open shared object file: No such file or directory
winneec opened this issue · comments
I tried to start the cs1.6 service, but I got this error. This error is described in the official document, but I followed the document, but I still have the same problem.Please advise.
steam@08d60943b3c9:~/steamcmd/cs16_ds$ ./hlds_run -console -game cstrike +port 27015 +maxplayers 16 +map de_nuke
Auto-restarting the server on crash
Console initialized.
Using breakpad crash handler
Setting breakpad minidump AppID = 10
Forcing breakpad minidump interfaces to load
Looking up breakpad interfaces from steamclient
Calling BreakpadMiniDumpSystemInit
Protocol version 48
Exe version 1.1.2.7/Stdio (cstrike)
Exe build: 19:52:19 Aug 3 2020 (8684)
STEAM Auth Server
Server IP address 172.17.0.2:27015
[S_API FAIL] SteamAPI_Init() failed; SteamAPI_IsSteamRunning() failed.
dlopen failed trying to load:
steamclient.so
with error:
steamclient.so: cannot open shared object file: No such file or directory
[S_API FAIL] SteamAPI_Init() failed; unable to locate a running instance of Steam, or a local steamclient.dll.
FATAL ERROR (shutting down): Unable to initialize Steam.
.
It's been some time since I last worked on a HL1 server, but I remember that it could be looking for the steamclient.so in the place where HLDSUpdateTool used to have it which is in "~/.steam/sdk32/steamclient.so", which this image provides for see:
Line 36 in 0883722
Can you double check if it exists in your container?
$ ls /home/steam/.steam/sdk32/steamclient.so
If it doesn't exists, then we need to find where it's looking for it somehow.
/home/steam/.steam/sdk32/steamclient.so
There is indeed this file in this path, but it is still prompted that there is no such file. This is where I am puzzled
The problem is solved, only need to add an environment variable.
export LD_LIBRARY_PATH=~./steam/sdk32:$LD_LIBRARY_PATH
Oh, that's nice. Would you consider opening a pull request for this?
Yes, but I still need to do some testing to make sure this is the correct solution.
Ah, even better. Thanks for taking care of this :)!
As a workaround, I'd recommend you set the variable yourself in your higher layer image for now. Until we can figure out at which path the hl1 servers are looking for the binary.
Well, I ignored this problem, and this problem can only be solved by setting different temporary environment variables according to different applications.
Maybe it can be changed like this:
export LD_LIBRARY_PATH=/home/steam/steamcmd/linux32:$LD_LIBRARY_PATH
export LD_LIBRARY_PATH=/home/steam/steamcmd/linux64:$LD_LIBRARY_PATH
Use two or only 64-bit.
My test conditions are limited,I can't guarantee that it has no problems.
Need a lot of applications to test whether this is feasible.
I'm trying to solve this problem, I feel sorry for this problem.
I was considering offering two versions of the image (32bit & 64bit).
EDIT:
According to this:
https://stackoverflow.com/questions/1706328/how-do-shared-libraries-work-in-a-mixed-64bit-32bit-system
Your approach should work, too. I'll give it a go.
having a similar problem with my quale live dedicated server.
during start:
[S_API FAIL] SteamAPI_Init() failed; SteamAPI_IsSteamRunning() failed.,
dlopen failed trying to load:,
steamclient.so,
with error:,
steamclient.so: cannot open shared object file: No such file or directory,
[S_API FAIL] SteamAPI_Init() failed; unable to locate a running instance of Steam, or a local steamclient.so.,
during build:
Warning: failed to init SDL thread priority manager: SDL not found
No worries. I have the exact same problem with the dedicated server I'm developing for my game right now. I'm investigating it.
Alright. I was able to fix the issue in my dedicated server. To sum it up:
[S_API FAIL] SteamAPI_Init() failed; unable to locate a running instance of Steam, or a local steamclient.so.
In my case was caused by unintentional usage of SteamAPI.Init() (Steamworks.NET) in a dedicated server. This essentially tried to load the "client-side" version of the API, which requires an active steam client session in the background (which is also the only true workaround to the issue). The correct way of initializing a server that uses SteamCMD is using GameServer.Init(). Since I was the developer, I also addressed the issue...
Practically, you can probably ignore the issue. LinuxGSM, agrees on this matter, at least in regards to SteamCMD. If the dedicated server you are hosting is correctly responding to A2S Queries and all other Steam integrations (lobby system, p2p networking over Steam) are working as expected you should be fine to do so.
So this covers the part you can't really do anything about. You might be able to suppress the issue by trying to put the SteamCMD's steamclient.so in the location the server is looking for. The way I managed to find these paths comes from this thread. Launch your binary using strace -f -o /tmp/file [binaryname], then search for steamclient.so in /tmp/file. Place the steamclient.so (32 or 64 bit) from SteamCMD in the locations that complain about "File not found".
This usually suppresses the issue, however the true way of fixing it would be from the side of the developer.
Let me know if you managed to progress on your specific game server use-cases @h4de5 @Marieyr, it's unlikely that I will be able to do anything else from my side.
I understand, thank you very much.
I am sorry - I don't really understand how to get it running again.
I use this repo: https://github.com/joshk0/docker-quakelive-server
server.sh is a wrapper for running run_server_x64_minql.sh which in turn runs the command below, which is, as far as I can see, already part of the steam game itself. So I don't know how to change SteamAPI.Init() to GameServer.Init() ? Should I contact the maintainer? would he know what to do?
export LD_PRELOAD=$LD_PRELOAD:./minqlx.x64.so,
LD_LIBRARY_PATH="./linux64:$LD_LIBRARY_PATH" exec ./qzeroded.x64 "$@",
[S_API FAIL] SteamAPI_Init() failed; SteamAPI_IsSteamRunning() failed.,
dlopen failed trying to load:,
steamclient.so,
with error:,
steamclient.so: cannot open shared object file: No such file or directory,
[S_API FAIL] SteamAPI_Init() failed; unable to locate a running instance of Steam, or a local steamclient.so.,
对不起， 我真的不知道如何再次运行它。
我使用此存储库： https://github.com/joshk0/docker-quakelive-server
server.sh是运行的包装器，它反过来运行下面的命令，这是，就我所看到的，已经是蒸汽游戏本身的一部分。所以我不知道怎么把 SteamAPI. init （） 更改为 GameServer. init （）？我应该联系维护者吗？他会知道该怎么做吗？run_server_x64_minql.shexport LD_PRELOAD=$LD_PRELOAD:./minqlx.x64.so, LD_LIBRARY_PATH="./linux64:$LD_LIBRARY_PATH" exec ./qzeroded.x64 "$@",[S_API失败]SteamAPI_Init（） 失败; SteamAPI_IsSteamRunning（） 失败.， dlopen 尝试加载失败：， steamclient.so，错误：， steamclient.so： 无法打开共享对象文件： 没有这样的文件或目录， [S_API FAIL] SteamAPI_Init（） 失败;无法找到正在运行的 Steam 实例或本地steamclient.so。
Please try to use this to temporarily solve this problem.
export LD_LIBRARY_PATH=/home/steam/steamcmd/linux32:$LD_LIBRARY_PATH
export LD_LIBRARY_PATH=/home/steam/steamcmd/linux64:$LD_LIBRARY_PATH
@Marieyr the quake live container is starting now :) thanks to everyone!
There seems to be no more startup errors - but I still cannot connect :( so i guess there must be something else wrong with it.
docker run -p 27960:27960/udp --link redis -d --name ql -e name="Test Server" -e admin="12345" dpadgett/ql-docker
If you still use this launch command, then you are not opening enough ports, since in your Dockerfile it says:
# ports to connect to: 27960 is udp and tcp, 28960 is tcp
EXPOSE 27960 28960
You are only opening udp in your docker run. Usually the initial server connection is done via tcp (client details etc), then udp is used for game traffic (positions, rotations etc.).
using my own docker-compose - which worked for quiet a while - but stopped like a week ago:
version: "3.3"
services:
ql-docker:
ports:
- "27960:27960/udp"
- "27960:27960/tcp"
- "28960:28960/tcp"
container_name: quakelive
environment:
- "location=Europe"
- "tags=ffa,ctf,instagib,ca,Europe,125fps"
- "admin=xxxx"
build:
context: ./docker-quakelive-server
image: quakelive:latest
sysctls:
- net.ipv6.conf.all.disable_ipv6=1
it did work for me prior to this - not sure what actually caused the problem, but after some restarts and rebuilds the server is available for at least two weeks again.