Segmentation Fault when starting the docker container

[john-ee]

Hi everyone,

I've just started playing the game and I want to host a server on my NAS. I ran the Docker-Compose file but I'm having issues.

As soons as I start the container after the game installs, I get the following error : ./launch.sh: line 80: 134 Segmentation fault (core dumped) DISPLAY=:99 LD_LIBRARY_PATH="$LD_LIBRARY_PATH:../Steamworks SDK Redist/linux64/" ./CoreKeeperServer "${params[@]}"

I feel like my hardware is weak but according to a few articles, I should be able to run it. My specs are the following : Processor : Intel(R) Celeron(R) N4505 @ 2.00GHz Memory : 4 Go Kernel : Linux 6.1.0-26-amd64 I'm running OpenMediaVault.

Here are the logs and my docker setup : CoreKeeperServerLog.txt core-keeper_core-keeper-dedicated.log docker-compose.txt .core.env.txt

Am I missing something ? The other issues haven't fixed anything for me.

[Diyagi]

Probably same as #53 Its an issue with permissions, should also be fixed by #62

[john-ee]

Probably same as #53 Its an issue with permissions, should also be fixed by #62

I don't understand what I should do to fix it. In #53 it seems the user is setting the same PUID:GUID from the host as the container in the user. Should I urn the same command ? I'm using Docker volumes instead of creating a folder then using it as a volume. I did that previously but I had rights issues, now at least it's able to download the game.

[Diyagi]

Well, it is indeed weird, volumes should not have permission issues, also this error is a bit different from the other issue

Steam API initialized
Steam server API failed to log in anonymously
CWorkThreadPool::~CWorkThreadPool: work complete queue not empty, 2 items discarded.
CWorkThreadPool::~CWorkThreadPool: work processing queue not empty: 3 items discarded.
Platform init Steam failed
 #0 PlayerMain(int, char**)
 #1 PlayerMain(int, char**)
 #2 ???
 #3  (Mono JIT Code) (wrapper managed-to-native) UnityEngine.DebugLogHandler:Internal_Log (UnityEngine.LogType,UnityEngine.LogOption,string,UnityEngine.Object)
 #4  (Mono JIT Code) UnityEngine.Logger:Log (UnityEngine.LogType,object)
 #5  (Mono JIT Code) (wrapper runtime-invoke) object:runtime_invoke_void (object,intptr,intptr,intptr)
 #6 mono_get_runtime_build_info
 #7 mono_runtime_invoke
 #8 mono_runtime_invoke
 #9 ???
 #10 ???
 #11 ???
 #12 ???
 #13 ???
 #14 ???
 #15 PlayerMain(int, char**)
 #16 __libc_init_first
 #17 __libc_start_main
 #18 ???

[john-ee]

There's the following message in the Docker logs, could that be linked to it ?

core-keeper-dedicated  | xvinfo:  Unable to open display :99
core-keeper-dedicated  | Failed to start Xvfb, retry: 1
core-keeper-dedicated  | _XSERVTransmkdir: Owner of /tmp/.X11-unix should be set to root

[Diyagi]

No, First two is just the script waiting for the xvfb to be ready and the second is just wrong permission for the x11 sockets folder, but it should be harmless.

[Diyagi]

Well, i guess u can try my in-dev image diyagi/core-keeper-dedicated these are the changed env vars

PUID=1000
PGID=1000
WORLD_INDEX=0
WORLD_NAME="Core Keeper Server"
WORLD_SEED=0
WORLD_MODE=0
GAME_ID=""
DATA_PATH="${STEAMAPPDATADIR}"
MAX_PLAYERS=10
SEASON=""
SERVER_IP=""
SERVER_PORT=""
DISCORD_WEBHOOK_URL=""
# Player Join
DISCORD_PLAYER_JOIN_ENABLED=true
DISCORD_PLAYER_JOIN_MESSAGE="$${char_name} ($${steamid}) has joined the server."
DISCORD_PLAYER_JOIN_TITLE="Player Joined"
DISCORD_PLAYER_JOIN_COLOR="47456"
# Player Leave
DISCORD_PLAYER_LEAVE_ENABLED=true
DISCORD_PLAYER_LEAVE_MESSAGE="$${char_name} ($${steamid}) has disconnected. Reason: $${reason}."
DISCORD_PLAYER_LEAVE_TITLE="Player Left"
DISCORD_PLAYER_LEAVE_COLOR="11477760"
# Server Start
DISCORD_SERVER_START_ENABLED=true
DISCORD_SERVER_START_MESSAGE="**World:** $${world_name}\n**GameID:** $${gameid}"
DISCORD_SERVER_START_TITLE="Server Started"
DISCORD_SERVER_START_COLOR="2013440"
# Server Stop
DISCORD_SERVER_STOP_ENABLED=true
DISCORD_SERVER_STOP_MESSAGE=""
DISCORD_SERVER_STOP_TITLE="Server Stopped"
DISCORD_SERVER_STOP_COLOR="12779520"

pay attention to the PUID and PGID, you will want to set these to the same IDs used by the nas (if u have access to the terminal just run the id command), this should also be safe to use with binds instead of volume assuming you set the right user and group IDs, let me know if it works.

Also, this is just an dev branch, this should be merged in this repo eventually, so if it works, remember that you will need to change it back to this repo once it merges.

[john-ee]

I doesn't work any better. In the core.env file, I put the PUID/PGID of the user I have to run Docker.

core-keeper_core-keeper-dedicated.log

[Diyagi]

Can you try setting both SERVER_IP and SERVER_PORT ?

[john-ee]

Still no success.

[Diyagi]

Well, its hard to say whats causing this as the Core Keeper server itself is hiding the errors from steamapi, all i know is that it is failing to login into steam.

// num3 is SERVER_PORT
SteamServer.LogOnAnonymous();
int num4 = 0;
while (num4 < 100 && !SteamServer.LoggedOn)
{
	Thread.Sleep(100);
	this.Update();
	num4++;
}
if (!SteamServer.LoggedOn && num3 == 0)
{
	Debug.LogWarning("Steam server API failed to log in anonymously");
	SteamServer.Shutdown();
	return false;
}

My only guesses is that the core keeper server is loading the wrong steamclient.so or theres some firewall issue not allowing it to connect to steam (tho steamcmd seems to connect to it just fine).

[mikaelts]

I think I'm having the same problem, could it be that waiting 10 seconds for the (anonymous) log in is not enough? It looks like the cmdline steamcmd waits much longer before it eventually manages to log in.

[eyeats]

I am also running into the same error. It looks like the server-data folder may be bisected into the server-files folder, but even trying to update the parameters to point to the same folder it doesn't seem to load properly.

I have also tried other non-official containers and they seem to fail in similar ways.

[Diyagi]

@eyeats Can you post logs and hardware specs ? We still dont know what exactly causes this seg faults and ive not been able to reproduce it.

[eyeats]

OS: Unraid MPG B760I EDGE WIFI 64GiB System Memory 12th Gen Intel(R) Core(TM) i7-12700K (onboard graphics)

Two Log files, Docker log is the only place the segmentation fault shows up: 2025-03-17_15-05-00.log dockerlog.txt

Full docker command from essentially the base template: docker run -d --name='Core-Keeper-Dedicated-Server' --net='bridge' --pids-limit 2048 --privileged=true -e TZ="America/Los_Angeles" -e HOST_OS="Unraid" -e HOST_HOSTNAME="hostname" -e HOST_CONTAINERNAME="Core-Keeper-Dedicated-Server" -e 'WORLD_NAME'='worldname' -e 'MAX_PLAYERS'='10' -e 'GAME_ID'='0' -e 'DATA_PATH'='' -e 'WORLD_INDEX'='0' -e 'CA_TS_FALLBACK_DIR'='/home/steam/core-keeper-dedicated' -l net.unraid.docker.managed=dockerman -l net.unraid.docker.icon='https://cdn2.steamgriddb.com/file/sgdb-cdn/logo/352114ae5d9447b65921f75e76b4a927.png' -l 'WORLD_SEED'='0' -p '27015:27015/udp' -v '/mnt/user/appdata/core-keeper-server/server-files':'/home/steam/core-keeper-dedicated':'rw' -v '/mnt/user/appdata/core-keeper-server/server-data/':'/home/steam/core-keeper-data':'rw' 'escaping/core-keeper-dedicated'

The thing that sticks out to me as inconsistent is the data directory: I have mounted a folder to /home/steam/core-keeper-data and then I see the path /home/steam/core-keeper-dedicated/CoreKeeperServer_Data referenced, even when I set the DATA_PATH parameter, maybe that is the expected behavior.

[Diyagi]

The issue seems to be the same

Steam API initialized
Steam server API failed to log in anonymously

Steam API is failing to login anonymously, im not sure why this is happening, could be an firewall issue but then SteamCMD would have an similar issue which does not seem to be the case.

[Diyagi]

Can you check if these ports are allowed for outbound connections ?

UDP remote port 27015-27050
TCP remote port 27015-27050

[eyeats]

I don't think anything is preventing outgoing communication. I am able to run the container manually and use steamcmd to login anonymously. I am not sure how to test the steam API manually.

[Diyagi]

Check for me if it works in local only mode, you just need to set an port using SERVER_PORT. If theres an port set and an connection to steam is not possible the game should fallback to local only mode. Send me the logs after.

[eyeats]

Definitely failed in a different way, but looks like you were right and it tried to start in local mode.

2025-03-17_23-22-57.log dockerlog2.txt

[Diyagi]

Well, it should not have failed, im kinda clueless on what the issue is, there were other ppl running it on unraid without any issues and it seems there nothing wrong on how the container was setup. Get me the kernel version uname -r, i will keep researching it to see if i eventually find something.

[eyeats]

6.6.78-Unraid

[eyeats]

@Diyagi I have figured out what is causing at least my issues but there are still a few unknowns. I was able to confirm your earlier assumption that something was blocking the outbound connection. I run Adguard Home, a dns level adblocker, and that was blocking something in the connection. If I remove Adguard Home from the DNS chain, the container starts working.

Now for the unknowns: The container works on my Windows PC with the same arguments, which is subject to the same DNS adblock. Adguard home doesn't report blocking anything to Steam, and adding api.steampowered.com doesn't help.

[Diyagi]

I ran an test with DNS earlier but both SteamCMD and Steam API did not worked, on top of that even with the Steam API failing to login there was no segmentation fault. It could be that theres something with how Unraid or OMV implements docker (or dockerman/podman) thats causing these issues or theres something at the kernel level thats could also be causing this.

My guess is that its something down to the kernel since its not the first time something like this happened.

Edit: you can override the dns server in the container so you dont have to change the DNS for the entire host.

[eyeats]

Good call! Adding the dns parameter got this working for me without modifying my network.

[sakkuntyo]

The same issue occurred, but it started successfully after hardcoding the following line in ./_launch.sh.

before

    DISPLAY=:99 LD_LIBRARY_PATH="$LD_LIBRARY_PATH:$installdir/../Steamworks SDK Redist/linux64/" \
           "$exepath" -batchmode -logfile CoreKeeperServerLog.txt "$@" &

after (replaced to fullpath include steamclient.so directory)

#    DISPLAY=:99 LD_LIBRARY_PATH="$LD_LIBRARY_PATH:$installdir/../Steamworks SDK Redist/linux64/" \
    DISPLAY=:99 LD_LIBRARY_PATH="/home/steam/Steam/steamapps/common/Core Keeper Dedicated Server/linux64/" \
           "$exepath" -batchmode -logfile CoreKeeperServerLog.txt "$@" &

this fullpath is may vary depending on the user and the environment. In a later comment, I explained that the environment I mentioned does not use this container. However, since this solution is necessary and functioning every time I set up the environment repeatedly, I believe it could also be a useful solution for this container.

[Diyagi]

The same issue occurred, but it started successfully after hardcoding the following line in ./_launch.sh.

before

    DISPLAY=:99 LD_LIBRARY_PATH="$LD_LIBRARY_PATH:$installdir/../Steamworks SDK Redist/linux64/" \
           "$exepath" -batchmode -logfile CoreKeeperServerLog.txt "$@" &

after

#    DISPLAY=:99 LD_LIBRARY_PATH="$LD_LIBRARY_PATH:$installdir/../Steamworks SDK Redist/linux64/" \
#           "$exepath" -batchmode -logfile CoreKeeperServerLog.txt "$@" &
    DISPLAY=:99 LD_LIBRARY_PATH="/home/steam/Steam/steamapps/common/Core Keeper Dedicated Server/linux64/"

This is not from this container tho ? This container uses https://github.com/escapingnetwork/core-keeper-dedicated/blob/2bcfbe748dfa3ff38e35c843e06695cabe9b7ee4/scripts/launch.sh#L49

[sakkuntyo]

I'm sorry, I was not talking about this container, but rather the _launch.sh source that I recently obtained with steamcmd. However, the error was almost the same.

[Fabricio20]

For anyone else having this issue, make sure you are using the correct docker image! Initially I was using arguser/core-keeper-dedicated and that one was causing segfaults. That's the first docker hub result on google. The second result is this github repository, which is actually escaping/core-keeper-dedicated:latest. This image worked flawlessly on the first try!