Sign in to follow this  

Connecting throws load error for client_temp/server_save


thasmo
  • Fixed

Set up a new dedicated server on Linux, but when connecting, it throws the error depicted in the screenshot.

20210312110217_1.jpg

Mind that the attached client log and server files are not from the same server/session/run.

client_log.txt

 


Steps to Reproduce

Create a new directory, create a `docker-compose.yml` file with this contents and add a valid token in the file:

version: "3.9"
services:
  world:
    image: yeetzone/dontstarvetogether
    container_name: world
    hostname: world
    depends_on:
      - data
    environment:
      TOKEN:
    ports:
      - "10999:10999/udp"
    volumes:
      - type: volume
        source: data
        target: /data
        read_only: true
  data:
    image: yeetzone/dontstarvetogether-data
    volumes:
      - type: volume
        source: data
        target: /data
        read_only: true
volumes:
  data:

Then execute `docker-compose up` within the directory. After the server has finished launching, start your local game client, open the console and connect via `c_connect("127.0.0.1")`.

Sign in to follow this  


User Feedback


A developer has marked this issue as fixed. This means that the issue has been addressed in the current development build and will likely be in the next update.

Is the error message suspicious because it mentions `client_temp`? Is this a server-side or a client-side problem?

The server log just prints this:

Quote

[00:06:00]: New incoming connection 192.168.0.1|51058 <...>
[00:06:00]: Client connected from [LAN] 192.168.0.1|51058 <...>
[00:06:00]: ValidateGameSessionToken ...
[00:06:01]: Client authenticated: (KU_...) thasmo
[00:06:01]: [Steam] Authenticated host '...'
[00:06:02]: There is no active event to validate against.
[00:06:06]: [Steam] SendUserDisconnect for '...'

 

Edited by thasmo

Share this comment


Link to comment
Share on other sites

Hello,

Same problem on :

- dedicated  Don't Starve Together: 455519 LINUX ;

- ubuntu 20.04 64bits : Linux XXXX 5.8.0-41-generic #46~20.04.1-Ubuntu SMP Mon Jan 18 17:52:23 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Thank you for all your work !!

Share this comment


Link to comment
Share on other sites

@zarklord_klei, I've attached the server log to the bug report. Mind that the attached server and client logs are not from the same server/session/run.

Edited by thasmo

Share this comment


Link to comment
Share on other sites

@zarklord_klei, inside /opt/storage/cluster/shard/save/server_temp/ there's a single file called server_save which seems to be some kind of binary/encoded file with a size of 348531 bytes. The files contents start with "KLEI     1DAQAAABAAAACyEBgA...".

Share this comment


Link to comment
Share on other sites

Hmmm, that is weird, I think i have found the fix for this, but its hard to say for certain, please let me know if the next hotfix resolves this issue.

  • Like 1

Share this comment


Link to comment
Share on other sites

@zarklord_klei, also, I noticed something different, probably not related, but after creating a `worldgenoverride.lua` file, somehow, when running `cat worldgenoverride.lua` it prints the contents with the string `KLEI 1` prepended to the file.

cat worldgenoverride.lua

KLEI     1 return {
        override_enabled = true,
        overrides = {
                extrastartingitems = "20",
                krampus = "often",
                regrowth = "veryfast",
                season_start = "summer",
                world_size = "huge",
        },
}

What is this behavior? Is this some left over debug code which accidently prepends this data to various files?

Edited by thasmo

Share this comment


Link to comment
Share on other sites

in the new update, we added support for settings to get changed, because of this behavior, we must rewrite worldgenoverride.lua, if somebody ran a command that set wildfires to "often" it would just get wiped, so we instead update worldgenoverride.lua to include the current world settings, which will prevent that from happening.

  • Like 1
  • Thanks 1

Share this comment


Link to comment
Share on other sites

@zarklord_klei, it seems the new patch/hotfix does not solve the issue. I'll attach a `zip` archive with the `cluster` directory so that you can have a look at it yourself.

I noticed that `client_temp/server_save` does not exist in the cluster directory, only `server_temp/server_save` exists.

Edited by thasmo

Share this comment


Link to comment
Share on other sites

So, I just tested an older codebase and the problem doesn't occur there. I assume that the issue is not specific to DST alone, it seems that it's directly related to how we run the server. Could be some permission problem or something. Gonna have to look at it more closely.

I think I figured it out. It seems that directory and file permissions for some critical files/directories were somehow not set properly, although listing the files and directories, it looked okay. The issue seems to be related to how Docker (wrongly) applies file and directory permissions when building a Docker image.

If anyone is interested, this is how I applied permissions in the Dockerfile:

# Set permissions.
RUN set -ex \
	&& chown -R "$STEAM_USER":"$STEAM_USER" "$STEAM_HOME" \
	&& chmod -R +x "$STEAM_HOME/scripts/" \
	&& chmod +x /usr/local/bin/dontstarvetogether \
	&& chmod +x /entrypoint.sh

And this is what seems to have fixed it; note the last line:

# Set permissions.
RUN set -ex \
	&& chown -R "$STEAM_USER":"$STEAM_USER" "$STEAM_HOME" \
	&& chmod -R +x "$STEAM_HOME/scripts/" \
	&& chmod +x /usr/local/bin/dontstarvetogether \
	&& chmod +x /entrypoint.sh \
	&& sync

So, in the end, this probably was some permission problem due to how Docker sets those in the Docker image. If someone else has similar issues, be sure to check permissions for files and folders related to running the server and persisting the config files etc.

Edited by thasmo

Share this comment


Link to comment
Share on other sites

PS: It's always permissions. :D

Removed the storage.zip, 'cause it contained some sensitive data (server token, KU_ ids etc.), I guess.

Share this comment


Link to comment
Share on other sites


Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now