pelican-eggs/yolks

Unable to start HLDS server using games:source image

r4sas opened this issue · 7 comments

r4sas commented

I'm unable to start clean HLDS server using games:source image. Log attached.

[Pterodactyl Daemon]: Checking server disk space usage, this could take a few seconds...
[Pterodactyl Daemon]: Updating process configuration files...
[Pterodactyl Daemon]: Ensuring file permissions are set correctly, this could take a few seconds...
container@pterodactyl~ Server marked as starting...
[Pterodactyl Daemon]: Pulling Docker container image, this could take a few minutes to complete...
Pulling from parkervcp/games 
Digest: sha256:39856c77bb2d5bcb9a342813ed945a0d5e8be4d8a623e3a20d81ee6817581a61 
Status: Image is up to date for ghcr.io/parkervcp/games:source 
[Pterodactyl Daemon]: Finished pulling Docker container image
steam user is not set.

Using anonymous user.

WARNING: setlocale('en_US.UTF-8') failed, using locale: 'C'. International characters may not work.
Redirecting stderr to '/home/container/Steam/logs/stderr.txt'
Looks like steam didn't shutdown cleanly, scheduling immediate update check
src/tier0/threadtools.cpp (4071) : Probably deadlock or failure waiting for thread to initialize.
[  0%] Checking for available updates...
Thread failed to initialize
src/tier0/threadtools.cpp (4071) : Probably deadlock or failure waiting for thread to initialize.
Thread failed to initialize
CWorkThreadPool::StartWorkThread: Thread creation failed.
Exiting on SPEW_ABORT
container@pterodactyl~ ./hlds_run -console -game cstrike -port 27015 -sport 26900 +map de_dust2 +ip X.X.X.X +maxplayers 6 -strictportbind -norestart
assert_20211026042814_4.dmp[26]: Uploading dump (out-of-process)
/tmp/dumps/assert_20211026042814_4.dmp


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 X.X.X.X:27015
[S_API FAIL] SteamAPI_Init() failed; SteamAPI_IsSteamRunning() failed.
src/tier0/threadtools.cpp (4071) : Assertion Failed: Probably deadlock or failure waiting for thread to initialize.
src/tier0/threadtools.cpp (4071) : Assertion Failed: Probably deadlock or failure waiting for thread to initialize.
Thread failed to initialize
src/steamnetworkingsockets/clientlib/steamnetworkingsockets_lowlevel.cpp (3267) : Assertion Failed: usecElapsed >= 0
src/steamnetworkingsockets/clientlib/steamnetworkingsockets_lowlevel.cpp (3267) : Assertion Failed: usecElapsed >= 0
src/common/pipes.cpp (879) : fatal stalled cross-thread pipe.
src/common/pipes.cpp (879) : fatal stalled cross-thread pipe.
src/common/pipes.cpp (879) : Fatal assert; application exiting
src/common/pipes.cpp (879) : Fatal assert; application exiting
_ExitOnFatalAssert
container@pterodactyl~ Server marked as offline...

For installation I changed egg's building container to ghcr.io/parkervcp/installers:debian, removed lib32gcc1 from apt installation list (it was already installed to container) and it finishes without any issues.

Just found a possible solution to this issue and submitted a PR to fix it in #14

Can you try again now that the sleep has been added to prevent the deadlock of steamcmd process?

r4sas commented

Still no luck:

[Pterodactyl Daemon]: Checking server disk space usage, this could take a few seconds...
[Pterodactyl Daemon]: Updating process configuration files...
[Pterodactyl Daemon]: Ensuring file permissions are set correctly, this could take a few seconds...
container@pterodactyl~ Server marked as starting...
[Pterodactyl Daemon]: Pulling Docker container image, this could take a few minutes to complete...
Pulling from parkervcp/games 
Digest: sha256:2964a436932010af5287d65e22a26f1d302059640aa7b29c275f898ca04aba95 
Status: Image is up to date for ghcr.io/parkervcp/games:source 
[Pterodactyl Daemon]: Finished pulling Docker container image
steam user is not set.

Using anonymous user.

Not updating game server as auto update was set to 0. Starting Server
container@pterodactyl~ ./hlds_run -console -game cstrike -port 27015 -sport 26900 +map de_dust2 +ip X.X.X.X +maxplayers 16 +sys_ticrate 1000 -strictportbind -norestart

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 X.X.X.X:27015
[S_API FAIL] SteamAPI_Init() failed; SteamAPI_IsSteamRunning() failed.
src/tier0/threadtools.cpp (4071) : Assertion Failed: Probably deadlock or failure waiting for thread to initialize.
src/tier0/threadtools.cpp (4071) : Assertion Failed: Probably deadlock or failure waiting for thread to initialize.
Thread failed to initialize
src/tier0/threadtools.cpp (4071) : Assertion Failed: Probably deadlock or failure waiting for thread to initialize.
src/tier0/threadtools.cpp (4071) : Assertion Failed: Probably deadlock or failure waiting for thread to initialize.
Thread failed to initialize
src/steamnetworkingsockets/clientlib/steamnetworkingsockets_lowlevel.cpp (3267) : Assertion Failed: usecElapsed >= 0
src/steamnetworkingsockets/clientlib/steamnetworkingsockets_lowlevel.cpp (3267) : Assertion Failed: usecElapsed >= 0
src/common/pipes.cpp (879) : fatal stalled cross-thread pipe.
src/common/pipes.cpp (879) : fatal stalled cross-thread pipe.
src/common/pipes.cpp (879) : Fatal assert; application exiting
src/common/pipes.cpp (879) : Fatal assert; application exiting
_ExitOnFatalAssert
container@pterodactyl~ Server marked as offline...

[Pterodactyl Daemon]: ---------- Detected server process in a crashed state! ----------
[Pterodactyl Daemon]: Exit code: 1
[Pterodactyl Daemon]: Out of memory: false

I think here some possibility of such problems due to usage of debian:stable-slim image as base. I'm using Debian 9 (stretch) as host:

# lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:    Debian GNU/Linux 9.13 (stretch)
Release:        9.13
Codename:       stretch

Your base OS shouldn't matter in a Docker container, but I can't replicate this myself, and any other alternative errors are niche SteamCMD web UI errors. Do you get this with other SteamCMD games or eggs?

r4sas commented

Just rebuilt container with buster-slim and tried to start with it.
Applied changes (--platform=$BUILDPLATFORM removed because building with docker build locally):

diff --git a/games/source/Dockerfile b/games/source/Dockerfile
index 8ce953a..efa3e01 100644
--- a/games/source/Dockerfile
+++ b/games/source/Dockerfile
@@ -20,7 +20,7 @@
 # SOFTWARE.
 #

-FROM        --platform=$BUILDPLATFORM debian:stable-slim
+FROM        debian:buster-slim

 LABEL       author="Matthew Penner" maintainer="matthew@pterodactyl.io"

@@ -32,7 +32,7 @@ ENV         DEBIAN_FRONTEND=noninteractive
 RUN         dpkg --add-architecture i386 \
                                && apt update \
                                && apt upgrade -y \
-                               && apt install -y tar curl gcc g++ lib32gcc-s1 libgcc1 libcurl4-gnutls-dev:i386 libssl1.1:i386 libcurl4:i386 lib32tinfo6 libtinfo6:i386 lib32z1 lib32stdc++6 libncurses5:i386 libcurl3-gnutls:i386 libsdl2-2.0-0:i386 iproute2 gdb libsdl1.2debian libfontconfig1 telnet net-tools netcat tzdata \
+                               && apt install -y tar curl gcc g++ libgcc1 libcurl4-gnutls-dev:i386 libssl1.1:i386 libcurl4:i386 lib32tinfo6 libtinfo6:i386 lib32z1 lib32stdc++6 libncurses5:i386 libcurl3-gnutls:i386 libsdl2-2.0-0:i386 iproute2 gdb libsdl1.2debian libfontconfig1 telnet net-tools netcat tzdata \
                                && useradd -m -d /home/container container

 USER        container

... and everything works. So my thought was correct.

Your base OS shouldn't matter in a Docker container

I already had such issues when tried to use Ubuntu 21.04 image in my other projects.

It appears to be an issue with your kernel version since the containers rely on the host OS kernel. Most likely, it's below 5 on stretch. You can view it with uname -r.

There can be compatibility issues with some specific kernel features that the newer distros are trying to use. However, host-guest kernel issues are very rare.

I'd recommend updating.

r4sas commented

Thanks, but I prefer to stay at oldoldstable/oldstable releases. It is easier rebuild container for myself.