satisfactory-server: Steamcmd Segmentation Fault on Subsequent Container Runs

My problem just disappears.

For who want to debug, can just try to use docker-compose run to avoid the container to be destroyed after the server fail.

docker-compose run --entrypoint /bin/bash --service-ports -- satisfactory-server

then manually use /init.sh to start the server.

I use /init.sh to start the server and the first try failed as described in this issue and the second run is just a success.

Also I can confirm that the issue is not related to lib libSDL3.so

libSDL3.so.0 failed: libSDL3.so.0: cannot open shared object file: No such file or directory

I got this libSDL3 line output still, but my server is already working.

That is such a fantastic news, I hope you will still consider trying with wolveix image until a resolution is found.

I am actually very interested to get that issue fixed and if applicable I don’t mind having a session with you, me and @wolveix to troubleshoot live.

Thanks for your update!

@wolveix Thanks for the hint, that did the trick for me.

@wolveix well, when I choose update to be true, it show an error with network when trying to connect and fail to connect to game.

Yet, I need to confirm further and perform another test, since I already decreased the resource limits (reserve 6GB and limit to 16GB [My VM was 18GB) it was failing, and when I reverted back to set update=false and increased VM Ram to 24 and limits to the one you provided (doc compose) it worked fine.

Anyway, I will test again when am back home different scenarios just to isolate the culprit of the issue and will report back.

I would like to thank you for your efforts in dockerizing the game server. Fantastic work.

@rnarma321 sounds like there’s a configuration issue in how you’re binding the mount 😃 Feel free to open a discussion request if you’re unsure/need help. I work with Docker daily at work 😄

The issue with this overarching GitHub issue is that I can’t personally reproduce it, no matter what I do. Until I can, fixing it is a little cumbersome. @erikjunker it’s great to find someone else that is experiencing the same issue! Well, not great for you of course, but hopefully it’ll cut down on the time needed to investigate the issue. Please try some of the steps I mentioned above, particularly try launching the container without any bind mount. This should work without any issues

I think I have been through all the suggestions in this thread with no success, but I did just try running the image without any bind mounts:

docker run -d --name=satisfactory-server-test -h satisfactory-server-test -e MAXPLAYERS=4 -e PGID=1000 -e PUID=1033 -e STEAMBETA=true -m 16G --memory-reservation=12G -p 7777:7777/udp -p 15000:15000/udp -p 15777:15777/udp wolveix/satisfactory-server:latest

This starts the server without any issues. I also cannot seem to reproduce the segmentation error after restarting the server. It passes the steam update with ease and starts the server right away.

I then started the server again, this time with a bind mount but to a completely blank folder:

docker run -d --name=satisfactory-server-test -h satisfactory-server-test -e MAXPLAYERS=4 -e PGID=1000 -e PUID=1033 -e STEAMBETA=true -v /volume1/docker/satisfactory-server-test:/config -m 16G --memory-reservation=12G -p 7777:7777/udp -p 15000:15000/udp -p 15777:15777/udp wolveix/satisfactory-server:latest

Again, the server starts without any issues - I can connect, play and everything works great. I then ran docker restart satisfactory-server-test and this throws the segmentation error:

[ 0%] Checking for available updates… [----] Verifying installation… Steam Console Client © Valve Corporation - version 1689642531 – type ‘quit’ to exit – Loading Steam API…dlmopen steamservice.so failed: steamservice.so: cannot open shared object file: No such file or directory OK Connecting anonymously to Steam Public…OK Waiting for client config…OK /home/steam/.steam/steamcmd/steamcmd.sh: line 39: 50 Segmentation fault (core dumped) $DEBUGGER “$STEAMEXE” “$@” Waiting for user info…

I tried this three times (each time with a clean folder), and it had a 100% reproduction rate.

Earlier I did not quite put it correctly: not only restarting, but also stopping and restarting again. Without a difference. I created a new project from scratch using the settings, not the rules of an existing project.

version: '3'
services:
    satisfactory-server:
        container_name: 'satisfactory-test-srv'
        hostname: 'satisfactory-srv2'
        image: 'wolveix/satisfactory-server:latest'
        ports:
            - '7777:7777/udp'
            - '15000:15000/udp'
            - '15777:15777/udp'
        environment:
            - MAXPLAYERS=4
            - PGID=1000
            - PUID=1000
            - STEAMBETA=false
        restart: unless-stopped
        deploy:
          resources:
            limits:
              memory: 16G
            reservations:
              memory: 12G

Still, I did a short test. I used the standard Docker Compose file recommended by you. Created a container without mounting the “config” folder. Removed the line: volumes: - '/path/to/config:/config' With the SKIP UPDATE = false Restarting the container, I get a fragmentation error. home/steam/.steam/steamcmd/steamcmd.sh: line 39: 50 Segmentation fault (core dumped) $DEBUGGER "$STEAMEXE" "$@"

Same issue after I upgraded from last year’s version eee7de98370e to f13f51f7abdf without cleanup. I will try to debug.

No. I will try.

@konstander huh, that’s interesting. Looks like they forked my repo to begin with (everything is laid out identically to an old commit), but they never adopted our permissions fixes.

That could potentially be where the issue lies? I’ll have a proper look through in a bit, but that’s really interesting 😅

For the sake of interest, I tried to launch an image of another author, check what will happen. You know what? Starts, stops restarts and no fragmentation errors. >< p.s. By the way, thanks to the update of the DSM interface in synology, the docker package has acquired the function of “launching projects”, including through the Docker Compose file. It is a pity that this did not solve the fragmentation problem.

@m3talliz3d nothing… The directory is empty. So I mounted /core correctly earlier, there are just no dumps there.

That is strange… everything is working fine now.

===== START ISSUE REPORT ===== Hardware: ESXi 6.7U3 OS: Linux satisfactoryd 5.4.0-153-generic #170-Ubuntu (Ubuntu 20.04.1 LTS) SMP Fri Jun 16 13:43:31 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux CPU: Intel® Xeon® CPU E5-2670 v2 @ 2.50GHz RAM: 10GB/11GB HDD: 19GB/98GB (20% used) ===== END ISSUE REPORT =====

Note: RAM = 23GB/24GB

T#1: (update=false) -> Ran docker compose up . -> connected to the game and it worked.

T#2: -> Stopped container with docker compose down . -> reverted update to true as default" . -> Started container. -> Connected to game successfully.

T#3: -> Stopped container with docker compose down . -> Set limits to –> Limit = 10 GB –> Reservation = 8GB -> Started container. -> Connected to game successfully.

T#4: -> Stopped container with docker compose down . -> Power off VM and change its RAM to 12GB instead of 24GB -> Started container. (with same docker-compose changes in T#3) -> Connected to game successfully.

I am not sure what was the issue exactly before but the error I had previously was

[2023.06.29-08.52.31:353][980]LogNet: NetworkFailure: ConnectionTimeout, Error: 'UNetConnection::Tick: Connection TIMED OUT. Closing connection.. Elapsed: 30.00, Real: 30.00, Good: 30.00, DriverTime: 68083.64, Threshold: 30.00, [UNetConnection] RemoteAddr: 172.18.0.1:60447, Name: IpConnection_2147481141, Driver: GameNetDriver NetDriverEOSBase_2147481943, IsServer: YES, PC: NULL, Owner: NULL, UniqueId: EOS:(EOS)3f9f7a418b434065adb3853ff12de642|000289f1418a4c7dbf726ddc36c37f89'

now it looks like everything is running smoothly.

error regarding libSDL3 looks like safe to ignore, it didn\t cause any issues on my side

satisfactory-server  | Loading Steam API...dlmopen steamservice.so failed: steamservice.so: cannot open shared object file: No such file or directory
satisfactory-server  | dlmopen libSDL3.so.0 failed: libSDL3.so.0: cannot open shared object file: No such file or directory
satisfactory-server  | OK

@Reticulmz What is your RAM available to be used or the one that WSL use/allocate?

I’ve been doing some digging around, and maybe it’s due to running out of stack space. Try checking with ulimit -a.

In my case, I think it’s because wsl2 didn’t free memory and steamcmd didn’t start due to lack of memory. I think you can avoid the error by specifying the memory limit or swap in .wslconfig for example.

Yeah, setting SKIPUPDATE=true will completely ignore SteamCMD, hence why it works 😄 I still don’t really understand why your specific environment isn’t handling SteamCMD properly, and crashing. I did update the image manually last night, but I merely rebuilt it in the hopes that an upstream update may resolve the issue for you.

I really appreciate your hard work investigating this issue, and wish that I had more to add. I’m pretty slammed with work right now, but I’m checking in when I can 😃

An interesting observation:

1. I delete the file in the config folder…\gamefiles\Factory Server.sh The container starts properly!
2. In the game, I make the primary server settings - the administrator’s name, password, etc. I try to load the save - the container crashes. This save file in single mode works. No mods are installed.

It was possible to load the server several times successfully with a save. Deleted the file every time FactoryServer.sh (yes, in the process of launching it, it was created anew and everything seemed to be going as it should).

Error again all in a circle, ohh God… home/steam/.steam/steamcmd/steamcmd.sh: line 39: 50 Segmentation fault (core dumped) $DEBUGGER "$STEAMEXE" "$@"

@wolveix

Oh wait, I’ve just spotted the segmentation fault error in your log. That’ll be the real issue.

Perhaps. All I understood was that the files are checked 100%, similarly, the files are downloaded 100% (if you delete everything). But then the server does not start. Perhaps some error during verification or transmission of an “error signal” to the log stops the process. I don’t understand well at this moment.

It usually ends there: home/steam/.steam/steamcmd/steamcmd.sh: line 39: 50 Segmentation fault (core dumped) $DEBUGGER "$STEAMEXE" "$@"

The spec you gave in place of a normal Docker run or Docker Compose file is interesting, that’s what Synology gives you, right? What did you specify when initially running the container?

I am using the docker application (package) in synology nas. The settings file I have given is the container configuration export file. Unfortunately, input options via the “console” (as on a PC) via the DSM synology interface (GUI) are not supported, I did not try using SSH. I repeat, earlier everything worked with your image. All container parameters are perfectly configured in the graphical shell of the docker application.