mirror of
https://github.com/GameServerManagers/LinuxGSM.git
synced 2026-04-24 21:56:01 +03:00
[GH-ISSUE #4713] [Bug]: vhserver update error "[ FAIL ] Updating vhserver: Checking remote build: SteamCMD" #2927
Labels
No labels
Atomic
Epic
cannot reproduce
command: backup
command: console
command: debug
command: details
command: fast-dl
command: install
command: mods
command: monitor
command: post-details
command: restart
command: send
command: start
command: stop
command: update
command: update-lgsm
command: validate
command: wipe
distro: AlmaLinux
distro: Arch Linux
distro: CentOS
distro: Debian
distro: Fedora
distro: RedHat
distro: Rocky Linux
distro: Ubuntu
distro: openSUSE
engine: goldsrc
engine: source
game: 7 Days to Die
game: ARMA 3
game: Ark: Survival Evolved
game: Assetto Corsa
game: Avorion
game: BATTALION: Legacy
game: Barotrauma
game: Battalion 1944
game: Battlefield 1942
game: Black Mesa: Deathmatch
game: Blade Symphony
game: Call of Duty 2
game: Call of Duty 4
game: Call of Duty: United Offensive
game: Counter-Strike 1.6
game: Counter-Strike 2
game: Counter-Strike: Global Offensive
game: Counter-Strike: Source
game: Day of Infamy
game: Dayz
game: Death Match Classic
game: Don't Starve Together
game: ET: Legacy
game: Eco
game: Factorio
game: Factorio
game: Garry's Mod
game: Half-Life
game: Hurtword
game: Insurgecy
game: Insurgecy
game: Insurgency: Sandstorm
game: Just Cause 3
game: Killing Floor
game: Killing Floor 2
game: Left 4 Dead 2
game: Minecraft
game: Minecraft Bedrock
game: Mordhau
game: Multi Theft Auto
game: Mumble
game: Natural Selection 2
game: No More Room in Hell
game: Pavlov VR
game: Post Scriptum
game: Project Zomboid
game: Quake 3
game: QuakeWorld
game: Red Orchestra: Ostfront 41-45
game: Return to Castle Wolfenstein
game: Rising World
game: Rust
game: San Andreas Multiplayer
game: Satisfactory
game: Soldat
game: Soldier of Fortune 2
game: Squad
game: Squad 44
game: Starbound
game: Stationeers
game: Sven Co-op
game: Team Fortress 2
game: Teamspeak 3
game: Teeworlds
game: Terraria
game: The Front
game: Unreal Tournament 2004
game: Unreal Tournament 3
game: Unreal Tournament 99
game: Unturned
game: Valheim
game: Wurm Unlimited
game: Zombie Master Reborn
game: label missing
good first issue
help wanted
info: alerts
info: dependency
info: docker
info: docs
info: email
info: query
info: steamcmd
info: systemd
info: tmux
info: website
info: website
needs more info
outcome: duplicate
outcome: issue resolved
outcome: issue resolved
outcome: issue unresolved
outcome: pr accepted
outcome: pr rejected
outcome: unconfirmed
outcome: wontfix
outcome: wrong forum
potential-duplicate
priority
pull-request
type: bug
type: feature
type: feature
type: feature request
type: game server request
type: refactor
waiting response
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/LinuxGSM#2927
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @historical-theology on GitHub (Dec 9, 2024).
Original GitHub issue: https://github.com/GameServerManagers/LinuxGSM/issues/4713
User story
Fresh Valheim server installation with LinuxGSM in Debian 12. Running ./vhserver update yields this error message.
Game
Valheim
Linux distro
Debian 12
Command
command: update
Further information
This issue was just mentioned in a separate issue thread by @jaumebecks:
https://github.com/GameServerManagers/LinuxGSM/issues/4588#issuecomment-2514955795
It is not isolated to my own setup.
Relevant log output
Steps to reproduce
No response
@Aquato commented on GitHub (Dec 10, 2024):
The same here.
On Satisfactory Server.
It is not necessarily the update function, as the check for update function is also affected and is certainly part of the update function.
The Steam version cannot be accessed, it seems.
@irobot73 commented on GitHub (Dec 10, 2024):
Same for most of the servers I run (PW, PZ, VH, SDTD).
Simply run SteamCMD manually & seems to work as expected
steam_upd.sh
steamcmd.txt
@Aquato commented on GitHub (Dec 11, 2024):
If you address the server with the parameter fu "force update" it also works manually. But it's all inconvenient and takes time.
@majorpdd commented on GitHub (Dec 12, 2024):
Same here for insurgency server
@freaky-m0 commented on GitHub (Dec 13, 2024):
It seems to me that steamcmd no longer provides the necessary information.
From
lgsm/modules/core_steamcmd.sh//fn_update_steamcmd_remotebuild():From
log/steam/appinfo_log.txt:@AndrewSav commented on GitHub (Dec 14, 2024):
We can confidently say that the old way does not work. I do not think you can blanketly judge "that steamcmd no longer provides the necessary information". Perhaps it changed, or perhaps the devloper need to come with an alternate way of doing this to fix the issue. For example we can see that this latest build id number is still publicly available here: https://steamdb.info/app/1690800/depots/?branch=public (I'm giving the satisfactory example, because this is the game server I have problems with) so it would be reasonable to assume there are working ways to retreive it.
@AndrewSav commented on GitHub (Dec 14, 2024):
Related: https://github.com/ValveSoftware/steam-for-linux/issues/11521 FWIW, the app info steamcmd command does work with an authenticated account (if you jump through the steam guard / 2FA hoops)
and it does work with a game server token (you need to have the game registered to the account in question). The latter may be a practical way to fix this, but that requires lgsm code changes as it cannot authenticate via those tokens at the moment.Turned out I got that last bit wrong and probably was using cached credentials instead when it worked.@dgibbs64 commented on GitHub (Dec 14, 2024):
We were hoping that once they completed the updates to the various appid's it would settle down. Its appears that is not the case
@freaky-m0 commented on GitHub (Dec 14, 2024):
I just wanted to say that this is the reason why it fails: An output from Steamcmd is missing. It is of course clear that there can be many reasons for this or different solutions. It should just help to understand/find the cause
Thanks for linking the related issue :)
@dgibbs64 commented on GitHub (Dec 15, 2024):
I would rather not have to go down the route of LinuxGSM having to use logins to get the info moving forward. It is still not clear what the solution is moving forward. If anyone has any success getting appid info without requiring login please let us know
@svanegmond commented on GitHub (Dec 15, 2024):
I poked around on this. My problem is with sfserver. It is the same problem, no app info returned from steamcmd.
While experimenting, I left off the +quit and entered
app_info_print 1690800interactively and got a response payload.Then I went into core_steamcmd.sh and removed the passage which deletes appinfo.vdk at line 170.
sfserver updatenow runs successfully.If I stack multiple app_info_print's on the command line I sometimes get an empty payload, like this:
I am still unable to reliably cause steamcmd to return a payload via a script without the step of doing this interactively.
@AndrewSav commented on GitHub (Dec 15, 2024):
You probably could run
steamcmdin backgroud, sleep a little and then kill it once the info is retreived. Terrible, I know. As a PoC:@FlaminSarge commented on GitHub (Dec 18, 2024):
Editing https://github.com/GameServerManagers/LinuxGSM/blob/master/lgsm/modules/core_steamcmd.sh#L186 with the solution presented in https://github.com/ValveSoftware/steam-for-linux/issues/9683#issuecomment-2515828207 (extra
+app_info_request APPID++login anonymous) worked for me for working around steamcmd's issue.My full replaced line:
@AndrewSav commented on GitHub (Dec 18, 2024):
Looks like it comes down to timing. If you cause the command to delay long enough to get the info before it quits you get the results. So padding it in any way to make it run longer seems to work.
@FlaminSarge commented on GitHub (Dec 18, 2024):
Right, but prior to some update, it would wait/block for app_info_print to finish before moving on to the next command, but not anymore, necessitating the extra commands to stall.
If this isn't something that can be reverted, may be useful to add
app_info_print_blockingor something to replicate old behavior. As it stands, though,app_info_printarbitrarily not printing anything despite the "requesting..." message seems like a bug, not a feature.@AndrewSav commented on GitHub (Dec 18, 2024):
That probably best to go somewhere where it can be actioned, e.g. https://github.com/ValveSoftware/steam-for-linux/issues/11521 linked above.
@dgibbs64 commented on GitHub (Dec 18, 2024):
Yeah, I suggest leaving comments on the steam-for-linux issues page. Upvote related issues as well. As currently this is something that Valve have broken and there is no decent workaround currently. Hopefully they sort it out soon. Until there is a reliable workaround we can use or a fix there isnt anything I can do currently.
@sahammer commented on GitHub (Dec 18, 2024):
Just wanted to chime in here and say, this change worked for me with Satisfactory as well as Valheim.
Edit: It worked for
./server cu- but there's no updates at the moment so cant test update.@Mystik-Spiral commented on GitHub (Dec 19, 2024):
This also worked for me to fix the command "l4d2server check-update" and the command "l4d2server update":
from:
remotebuildversion=$(${steamcmdcommand} +login "${steamuser}" "${steampass}" +app_info_update 1 +app_info_print "${appid}" +quit | sed -e '/"branches"/,/^}/!d' | sed -n "/"${branch}"/,/}/p" | grep -m 1 buildid | tr -cd '[:digit:]')
to:
remotebuildversion=$(${steamcmdcommand} +login "${steamuser}" "${steampass}" +app_info_request "${appid}" +login "${steamuser}" "${steampass}" +app_info_update 1 +app_info_print "${appid}" +quit | sed -e '/"branches"/,/^}/!d' | sed -n "/"${branch}"/,/}/p" | grep -m 1 buildid | tr -cd '[:digit:]')
Thank you freaky-m0 and sahammer.
@Aquato commented on GitHub (Dec 19, 2024):
Some chars are missing here. Must be ...
to: remotebuildversion=$(${steamcmdcommand} +login "${steamuser}" "${steampass}" +app_info_request "${appid}" +login "${steamuser}" "${steampass}" +app_info_update 1 +app_info_print "${appid}" +quit | sed -e '/"branches"/,/^}/!d' | sed -n "/\"${branch}\"/,/}/p" | grep -m 1 buildid | tr -cd '[:digit:]')the
\will be deleted if you do not mark the text as code.But then the code works again for me :) and the remote build can be accessed. Thx to all!
@dgibbs64 commented on GitHub (Dec 19, 2024):
Looks like we might have a workaround. I will do some testing with this suggestion to see how well it works. If successful I will get a hot fix out 😊
@Mystik-Spiral commented on GitHub (Dec 19, 2024):
@Aquato Yes, you are correct. I posted without marking as code and it stripped the back slashes. Sorry about that and thank you for correcting! What you have is correct, but I am posting again as confirmation:
In:
core_steamcmd.sh
from:
remotebuildversion=$(${steamcmdcommand} +login "${steamuser}" "${steampass}" +app_info_update 1 +app_info_print "${appid}" +quit | sed -e '/"branches"/,/^}/!d' | sed -n "/\"${branch}\"/,/}/p" | grep -m 1 buildid | tr -cd '[:digit:]')to:
remotebuildversion=$(${steamcmdcommand} +login "${steamuser}" "${steampass}" +app_info_request "${appid}" +login "${steamuser}" "${steampass}" +app_info_update 1 +app_info_print "${appid}" +quit | sed -e '/"branches"/,/^}/!d' | sed -n "/\"${branch}\"/,/}/p" | grep -m 1 buildid | tr -cd '[:digit:]')@dgibbs64 commented on GitHub (Dec 19, 2024):
Any reason why we need +login twice?
edit: becuase it dont work without login twice 🙄
@AndrewSav commented on GitHub (Dec 19, 2024):
My opinion, is that anything that is running long enough to let the async call to get the information will work. So if you do not pad it with enough commands, such as login, it still sometimes not going to get the data. Of course it all depends on timing and therefore results may wary, but the longer it takes the more probability the data will be there.
@AndrewSav commented on GitHub (Dec 19, 2024):
FWIW the above "fix" works most of the time but not all of the time during my testing. About 1 time out of ten on my box it still returms nothing.
@Mystik-Spiral commented on GitHub (Dec 20, 2024):
@AndrewSav Here is a very small change (added +logoff before +quit) and I am curious if it helps you go from 90% to 100% working:
remotebuildversion=$(${steamcmdcommand} +login "${steamuser}" "${steampass}" +app_info_request "${appid}" +login "${steamuser}" "${steampass}" +app_info_update 1 +app_info_print "${appid}" +logoff +quit | sed -e '/"branches"/,/^}/!d' | sed -n "/\"${branch}\"/,/}/p" | grep -m 1 buildid | tr -cd '[:digit:]')@AndrewSav commented on GitHub (Dec 20, 2024):
@Mystik-Spiral I think I'll leave it where it is. I wrote an automation script to demonstrate the failures, but with the script it is not failing any more, only ocasionally fails when running manually from the command line. Probably comes down to some wierd timing and good enough.
@dgibbs64 commented on GitHub (Dec 20, 2024):
Yeah, sounds like the hotfix have reduced the problem but probably to got rid of it totally...which is a step in the right direction.
@FlaminSarge commented on GitHub (Dec 21, 2024):
The only purpose of the second login/etc is to stall for long enough that the app_info_request finishes and populates the temp vdf files, so that the followup app_info_print just reads from the vdf instead of fetching from remote again.
The core issue is that they changed app_info_print to not block+wait for response, and instead made it print its info as a side-effect during execution if the info was available, or no-op while fetching the info if it was not available. This seems like a bug on steamcmd's end and we'll have to keep track of https://github.com/ValveSoftware/steam-for-linux/issues/9683 for when they eventually fix it. The other option is to loop, say, 10 times trying to fetch the info (without deleting local temp vdf) to see if app_info_print will eventually get it on its own, which may be a bit more deterministic than hoping that 2 logins is enough stall time for the request to finish.
@AndrewSav commented on GitHub (Dec 28, 2024):
Just from today, after updating lgsm:
As you can see failed the first time succeeded on the seccond attempt
@majorpdd commented on GitHub (Dec 28, 2024):
Works first time on ./inssserver u
@WildPenquin commented on GitHub (Aug 28, 2025):
I'm having this error currently on a Valheim server on the public beta.
The curious thing is, I have two linuxgsm containers, configured identically safe for the port. The other one works with
/app/vhserver cu, the other one does not (with the [ FAIL ] when doing the check).... and as I was typing this, I did a force update. Now cu still shows it as not up-to-date. Doing an update now works.Maybe the cu fails when the server configuration is on the public beta, but the server files are on the stable branch? That could be another bug (if you've initialized the server on stable, and switch to beta, you need to do a force-update once?).
Sorry for the noise, if this issue I'm having is another one and not relevant here.