Is there a way for a dedicated server to automatically restart whenever a hotfix comes out?

[lakhnish]

As per the title, is there a way for dedicated servers to automatically restart itself whenever a hotfix comes out?

[Daniel86268]

There's no built in way to do that.

However, you can try running a script, that regularily checks of an update is available, and if so, updates+restarts the server, such as the one that b l a n k has written:

 

 

[b l a n k]

On 6/8/2023 at 8:58 PM, Daniel86268 said:

There's no built in way to do that.

However, you can try running a script, that regularily checks of an update is available, and if so, updates+restarts the server, such as the one that b l a n k has written:

 

 

Unfortunately, I can't keep this topic up-to-date anymore as it is archived. The script doesn't work anymore, partly because of the steamcmd API is outdated, so I made it work again on my github repo.

On 6/5/2023 at 2:37 AM, lakhnish said:

As per the title, is there a way for dedicated servers to automatically restart itself whenever a hotfix comes out?

https://github.com/Sad-theFaceless/DST_DedicatedServer_AutoUpdate

[Philip.]

Actually, you do not have to use any external scripts. You can basically do all this directly from the Lua side of the game. The only requirement is to make sure your server will be restarted after exiting with an error status code (simply after crashing) which is what you probably want anyway. On Linux you can use the built systemd to create a service or if you have a provider then they most likely do this for you.

The steps are the following:

1. Retrieve the latest version from https://s3.amazonaws.com/dstbuilds/builds.json which is the way the game itself checks whether it's up-to-date. So no web scrapping or additional language or library dependencies needed!

2. Check whether the latest release version matches with the APP_VERSION constant.

3. If not, announce the version mismatch, save the game and disconnect all the connected clients.

4. Now just call TheSim:Crash() to make a clean engine side crash, which basically forces the server to reboot from inside.

5. Your server should be booted up, and since we assume you run steamcmd update check before the server process, it should be updated as well. But this is very standard stuff which even the official starting scripts do.

[b l a n k]

16 hours ago, Philip. said:

Actually, you do not have to use any external scripts. You can basically do all this directly from the Lua side of the game. The only requirement is to make sure your server will be restarted after exiting with an error status code (simply after crashing) which is what you probably want anyway. On Linux you can use the built systemd to create a service or if you have a provider then they most likely do this for you.

The steps are the following:

1. Retrieve the latest version from https://s3.amazonaws.com/dstbuilds/builds.json which is the way the game itself checks whether it's up-to-date. So no web scrapping or additional language or library dependencies needed!

2. Check whether the latest release version matches with the APP_VERSION constant.

3. If not, announce the version mismatch, save the game and disconnect all the connected clients.

4. Now just call TheSim:Crash() to make a clean engine side crash, which basically forces the server to reboot from inside.

5. Your server should be booted up, and since we assume you run steamcmd update check before the server process, it should be updated as well. But this is very standard stuff which even the official starting scripts do.

I'm really curious about this, do you mind sharing your .service file ?

As a non-modder, I have no clue about the "Lua side of the game" either... How do you do know what command to send, like "TheSim:Crash()" ?

 

By the way, I believe retrieving the version from https://s3.amazonaws.com/dstbuilds/builds.json , despite its advantages, is a bad practice for 3 reasons. It looks like the versions are added manually by the devs, as a google search shows some versions are forgotten inbetween builds. It's more reliable than https://api.steamcmd.net/v1/info/343050 , but less reliable than the actual Steam API. Also, it gives the DST version, not the DST Dedicated Server one, and finally, it's unrelated to the Steam depot actual build version. Even though everything seems to be updated along, so the 2 last reasons don't really matter :'D I'm just being fussy

[Philip.]

9 hours ago, b l a n k said:

I'm really curious about this, do you mind sharing your .service file ?

[Unit]
After=network.target

[Service]
Restart=on-failure
RestartSec=60 # Do not restart immediately
User=dstserver
ExecStart=<PATH TO YOUR RUN SCRIPT>

[Install]
WantedBy=multi-user.target

Note that this method will only work if you start the Master shard in the original process. For a forking run script, it looks like the exit status codes won't propagate to the parent process and therefor wont trigger the "on-failure" event.

9 hours ago, b l a n k said:

It looks like the versions are added manually by the devs, as a google search shows some versions are forgotten inbetween builds

I really doubt that there is no kind of automatization here. Yes, versions from beta branches are not there but you most likely do not need them anyway.
As of my experience from using it for about 2 years now, there were no problems at all. Using a whole Steam API library just for this simple task seems to be a bit too complex.

What endpoints does the Steam API use for checking the versions?

[lakhnish]

Is there a way to do this for other operating systems? 

This stuff seems beyond my ability

[Philip.]

3 hours ago, lakhnish said:

Is there a way to do this for other operating systems? 

What operating system do you mean? Since all the replies here are releated to Linux I assumed you are using Linux.

[lakhnish]

15 minutes ago, Philip. said:

What operating system do you mean? Since all the replies here are releated to Linux I assumed you are using Linux.

I'm on Windows (and am OP of the thread).

[b l a n k]

5 hours ago, Philip. said:

[Unit]
After=network.target

[Service]
Restart=on-failure
RestartSec=60 # Do not restart immediately
User=dstserver
ExecStart=<PATH TO YOUR RUN SCRIPT>

[Install]
WantedBy=multi-user.target

Note that this method will only work if you start the Master shard in the original process. For a forking run script, it looks like the exit status codes won't propagate to the parent process and therefor wont trigger the "on-failure" event.

I really doubt that there is no kind of automatization here. Yes, versions from beta branches are not there but you most likely do not need them anyway.
As of my experience from using it for about 2 years now, there were no problems at all. Using a whole Steam API library just for this simple task seems to be a bit too complex.

What endpoints does the Steam API use for checking the versions?

Thanks

So instead of using a second bash script, you just do the things inside your run script and run a service, right ? I suppose you'd have to do that for every server you run in parallel then ?

I have no clue about the endpoint used by the function get_product_info from the python lib, it's somehow now displayed by any debug log... I just know you need to be authenticated to use it.

1 hour ago, lakhnish said:

I'm on Windows (and am OP of the thread).

Do you host your Dedicated Servers on a Windows server, or on your Windows desktop you use to play with ?

[Philip.]

36 minutes ago, b l a n k said:

So instead of using a second bash script, you just do the things inside your run script and run a service, right ? I suppose you'd have to do that for every server you run in parallel then ?

You just have to make Master shard process the parent process (the starting process of the service) and other secondary shard processes it's children. Then if the parent is crashed the forked processes will exit as well. Something like a chain, or domino.

[lakhnish]

2 hours ago, b l a n k said:

Do you host your Dedicated Servers on a Windows server, or on your Windows desktop you use to play with ?

I followed the Klei guide on setting up the dedi server so I can host a dedi server on my computer when I play with other people.

[b l a n k]

1 hour ago, Philip. said:

You just have to make Master shard process the parent process (the starting process of the service) and other secondary shard processes it's children. Then if the parent is crashed the forked processes will exit as well. Something like a chain, or domino.

I see. Well if you feel like this is the best way to auto-update your servers, don't hesitate to make a step-to-step tutorial about this method! Don't make a topic for it though, as they get archived and you won't be able to modify it afterwards...

16 minutes ago, lakhnish said:

I use my Windows desktop.

I followed the Klei guide on setting up the dedi server so I can host a dedi server on my desktop for when I play with others.

Alright, it's possible to have a version of my script in powershell, but I'd have to find a good and clean alternative to "screen" and cron jobs... I don't know if and when I will make that, but I will ping you if it's done someday!

[Philip.]

47 minutes ago, lakhnish said:

I followed the Klei guide on setting up the dedi server so I can host a dedi server on my computer when I play with other people.

Then why the need of a relatively complex auto-updating system when you can just update it manually? I mean, from what I understood, the dedicated server is only active when you are, so that shouldn't be a problem or am I missing something?

[lakhnish]

1 hour ago, Philip. said:

Then why the need of a relatively complex auto-updating system when you can just update it manually? I mean, from what I understood, the dedicated server is only active when you are, so that shouldn't be a problem or am I missing something?

I know people who host their own 24/7 community dedicated servers and having this type of info would be useful for them and my future self if I decide to do my own 24/7 dedicated server.

[Philip.]

10 hours ago, lakhnish said:

I know people who host their own 24/7 community dedicated servers and having this type of info would be useful for them and my future self if I decide to do my own 24/7 dedicated server.

Windows (not Windows server) is not build for 24/7 service and server hosting. So if you decide someday to host such a non-stop dedicated server, I would highly recommed using some Linux distribution. Not just for stability but also performance, since with Windows comes the additional overhead of all the GUI stuff and user applications, and you do not really want to pay for that.