[New] Server OS and SRCDS version

bigmazi

bigmazi

Active Member
What is the OS TF2C servers are running on? And also what's the version+build id of SRCDS you use?

Interested because I personally can't set Linux server up - it tends to crash constantly at random times with random meaningless messages about corrupted memory. Tried on different machines with purest server installation - latest SRCDS downloaded from Steam + 2.0.3 TF2C out of the archive - nothing else, no sourcemod, no metamod, nothing.

I hope it's the right place to ask such question.
 
I believe valve officially recommends ubuntu for SRCDS servers, but we've generally run them without issue on CentOS 6 thru 8.

Make sure you're using SRCDS2013 multiplayer and not a different srcds version.

If you post the specific exact memory error you're getting we might be able to give more specific help

The other thing you can try is installing Accelerator, which is an add-on that gives you somewhat more useful crash dumps and offers a little bit of assistance in interpreting them.
 
Thanks for OS info, may I know exact SRCDS2013 version you're using? I obviously didn't mean whether it's 2013 or 2007, I'm talking about build ID of 2013th DS.

As for errors, those I remember so far:
  • malloc() asserion failed
  • corrupted double-linked list
  • received SIGABRT
  • received SIGSEGV (including due to NULL dereference)
Once again, completely pure servers out of the box. Meaning there are only 2 type of game binaries that can malfunction: either TF2C or SRCDS. I highly doubt #1, though speculation about #2 has a place: and if we're using SRCDS with different build IDs, it could confirm this version. (upd: to clarify, I mean that I have a hypothesis that newest tf2c version is incompatible with newest srcds on linux rather than either of them doing something wrong separately)

If it's not game binaries, then it might be something in the environment, maybe in OS, but for now this question is aimed at checking speculation about SRCDS binaries.
 
Last edited:
I'll make a note to check next time I'm doing server maintenance and let you know. But from the errors you're describing, one thing to check is SELinux configuration. We've seen some weirdness with that enabled and certain settings not playing nice with SRCDS mods and/or sourcemod extensions. The other thing - how much memory do your systems have? These are definitely errors you will get if the system doesn't have enough resources to run the server(s)
 
Yeah, I can reproduce this. I use Debian Unstable on my personal server and I've similarly seen random crashes in srcds_run, even with a purely vanilla setup. They're annoying ones too because it's unable to auto-restart from them. You might look into using a container of a known-good distribution that's still supported, like Debian 10 or Ubuntu 18.04.
 
Machine #1 provides 160 GB. Nuff said.
Machine #2 was tried with 1-4 GB: When it's really close to exceediing global limites, it aggressively deallocates memory to to keep usage somewhere in between 90-100 MB so I assume that's the actual memory requirement. When it has a room, it deallocates lazily, moving towards 0.5 GB.

Memory capacity doesn't seem to be the issue - it crashes at different memory usage and different free space remaining.
 
sniffy194 said:
Yeah, I can reproduce this. I use Debian Unstable on my personal server and I've similarly seen random crashes in srcds_run, even with a purely vanilla setup. They're annoying ones too because it's unable to auto-restart from them. You might look into using a container of a known-good distribution that's still supported, like Debian 10 or Ubuntu 18.04.
Click to expand...
At least now I know I'm not alone. You too ;)

VintagePC said:
I'll make a note to check next time I'm doing server maintenance and let you know.
Click to expand...
Thanks. But still, may I at least know when you're gonna do it? I wanna make plans, and if your word is coming at the next month, I doubt I'll wait for it instead of moving back to Windows.
 
should have an answer later this evening when I sit down at my desktop after dinner.
 
VintagePC said:
version : 5394425
Click to expand...
After aknowledging this number and toying with SRCDS and TF2Classic, I can say that it's not SRCDS version. I assume you typed "version" into server console?

First of all, why I do, in fact, think this doesn't give the answer we're looking for:
  • It differs from version info provided by Steam
  • It prints exactly same regardlesss of what SRCDS binaries are virtually present
  • It prints same number from TF2Classic client
  • When SRCDS running another mod (Open Fortress, for instance) it finally starts to give **another** number - but in this case it only shows that it prints game version it's running rather than its own.
So far I've come up with these ways to get the version:
  • If it was downloaded via SteamCMD, there is <srcds folder>/steamapps/appmanifest_244310.acf file, inside it there is "buildid" key, which value is the answer
  • If it was downloaded via Steam client, same file is located here: Steam/steamapps/appmanifest_244310.acf
  • If it was downloaded via Steam client and Steam is still present on the machine, build id can be seen in Steam client here:
    Library -> Source SDK Base 2013 Dedicated Server -> Properties -> Update
Alternatively, a very promising way to compare versions would be comparing sizes of indiviual .so files. So, if you wouldn't mind, can you please send me SRCDS/bin folder you're using so I could compare each file one-by-one?

Actually, if my hypotesis is correct, this becomes very importart. If, on Linux, latest SRCDS virtually doesn't support latest TF2C, it means that server owners, including VaultF4, should resist from updating SRCDS; while those who want to start a new server, should download older version - which apply new rules in setting up server.
 
hah, trust valve to make something relatively simple so complicated. I'll rummage around after work and see what I can get you
 
found this on my desktop:
- "buildid" "6982827"

I believe it's the same as the servers since I pulled a copy to do local testing at one point. However, the equivalent files on the live servers no longer exist because the original download happened on a retired machine and we have a custom deployment system.

if it helps, here are a list of MD5s from the bin/ folder:

18d88a8e06ca8bc93849d74b03e64e0f basehaptics.txt
fb5c09cc8bbea0200384fcc743899fa0 crashhandler.so
3375f3eecf550a2c6cc822f478530d4b datacache_srv.so
c95e9687bcc56d0dc72b0487ab95cd00 dedicated_srv.so
65e87cb0ccb487686af01d13a3822ae2 engine_srv.so
8bd77e393f19ce0f79f58a78c76a10de filesystem_stdio.so
fd0fbfac390be3882fadb0a6af9ba5cc libgcc_s.so.1
479be3b457de6f1ecf8f6e06c5972ee5 libprofiler.so.0
4f9c911de2276f988afaf47659a8367f libstdc++.so.6
0003d6ff65ffafb50897f434e9d68149 libsteam_api.so
1c08b62ffa6baffb76e9f0832f930b17 libtcmalloc_minimal.so.4
b153c4b7d12c0cb218101ab42e7381b7 libtier0.so
2a6c6802f7017fd0fd345a2053f25439 libtier0_srv.so
05c8a50292ceb1d6563abeb4502a3169 libtier0_s.so
3fe35205a8e9102eee10f1ad00c4f644 libvstdlib.so
5df3b0b9d5df5bb3dacedad8c8e43ae4 libvstdlib_srv.so
6fa9231d6192203e1da7b476dafaf9b3 libvstdlib_s.so
f6499a944bfb3ae8040afd9f75e70a02 materialsystem_srv.so
4361a90f22fcfa2ffb4d4178a7993e36 replay_srv.so
4ca2fd64d5877b2960ecb0a9e3fa90f7 scenefilecache_srv.so
cec8f52eadb61b8435c1fb6a307fd3a0 shaderapiempty_srv.so
f8fd984e445e87bf1289ae41f03e9648 soundemittersystem_srv.so
8d19e5924b1369dc57be09b2032413e1 steamclient.so
47911eaf2c06ba65712692f38273c59d studiorender_srv.so
c61d104d11163afce08cb2ee81245a44 vphysics_srv.so
605d6b088733ecb4747ab00bb8261f0a vpk_linux32
 
BuildID matches
BUT
Not hashes

I trust hashes more

Samples:
dedicated_srv.so
> 56c82ba142ba10a6fe8201d2f21482e4
> c95e9687bcc56d0dc72b0487ab95cd00
engine_srv.so
> 85b9b77524daeb72871a9d34ecbc3582
> 65e87cb0ccb487686af01d13a3822ae2
vphysics_srv.so
> 6a041169c0114bfbca15149669e02fa8
> c61d104d11163afce08cb2ee81245a44

My binaries are obtained via both SteamCMD and Steam Client - both ways resulted in same files downloaded.

So, you indeed have an older version. On top of that - the fact that you have version file claiming you have the newest one - tells us that we don't even know what your actual version is.

May I ask you to share the bin folder? + srcds_run & srcds_linux executables
And sourcemod gamedata files too? Most likely those must be older as well - to work with older binaries.

Btw what Sourcemod and Metamod versions do you use?
 
Sorry, got sidetracked today. I'll get back to you first thing tomorrow.
 
Yep, files are indeed different. You use outdated version. And I guess, that's what protects you from crashes. Thanks for the upload.

As for gamedata, though... I'm sorry, but that's not the situation where such words can convince. Are you 100% sure you know how updates work? Do they check for binary version or they are always are newest for given app? Are you 100% sure autoupdates are enabled? I, personally, can't give a guaranteed answer for either of those.

I understand that "gamedata should be fine", and I'm sure your files are fine for given environment, the question is WHAT exactly is fine. Difference between binary files is a fat chance for gamedata becoming wrong and causing malfunction while using Sourcemod stuff.

Also MM and SM have third number after second dot for their full version definition, may you provide those as well, please?
 
Well that's unfortunate... but it does suggest something external to SRCDS. I'm guessing it doesn't behave like that if you try other SDK2013 based mods?
 
You must log in or register to reply here.

Funding Progress To Date

VaultF4 on Steam


48181 Members
(8418 Online 584 In-Game)
Join the group
Back
Top Bottom