Refactor entrypoint script to properly handle custom commands

[thasmo]

Currently the entrypoint script just initializes some things and forwards arguments to the null-renderer. We should refactor the entrypoint script to handle useful commands like update, reset etc.

• help
  Print all available options.
• start --update=[true|false|game|mods] default
  Start the server and optionally update files.
  true is default and updates game and mods.
  false skips updates.
  game updates the game only.
  mods updates mods only.
• update --type=[all|game|mods]
  Run game and mod updates and stop the container.
  all is default and updates game and mods.
  game updates the game only.
  mods updates mods only.
• log --type=[server|chat]
  Return a log to stdout.
  server is default and prints the server log.
  chat prints the chat log.

[BraisGabin]

I was thinking about this. A posible no-complete list of commands:

• start - Default. If you don't write nothing this is executed. Run the server
• update - Updates the game and the mods and stops the container after that.
• backup - Generates a .tar.gz. I don't know how and where but something like this would be nice.
• log - Prints all the log. It'll be great if we can make things like docker start container log | more or docker start container log | grep login > login_reports.log
• logchat - Same as log but with the chatlog.

I understand that this commands are used in this way:

docker run [...] dstacademy/server start
# or
docker start my_server_container update

We don't need stop or restart. Those are free:

docker stop my_server_container
# or
docker restart my_server_container

I was thinking about a console command too. But I think that it must work in other way... I need to research a bit more about ENTRYPOINT too...

[thasmo]

It's possible to attach to the running server/console just via docker attach <container>.

[thasmo]

Be sure to check out ENTRYPOINT and CMD and i.e. the MySQL entrypoint script, or any other official image. They've best-practice baked in. :)

[thasmo]

I vote for start as default and update for running the steam update script and exiting.

I don't think we need backup, server administrators only need to backup volumes and how they do that, is their issue. I think creating a backup command will not add something useful to the container, which is better than anything people can easily do with a volume.

Printing logs sounds interesting. What do you think about log --type=[server|chat], and server is the default?

In addition, what I think should be implemented is signal trapping. I don't have too much experience with this, but we need to make sure, that the DST server shuts down and saves the world, when someone runs docker stop <container>. We need to listen for the SIGTERM and maybe also the SIGKILL signals and shuts down the DST server cleanly.

Thoughts?

[thasmo]

• start --update=[true|false] Starts the server and optionally checks for updates.
• update Checks for updates but exits afterwards.
• log --type=[server|chat] Returns/prints a log.

Just fooling around. :)

[BraisGabin]

About "shut down the DST server cleanly". Is there any wiki article or forum topic talking about best practices? I mean, what must you do to stop a DST server cleanly? All the guides closes the server and that's it.

A lot of game servers send a broadcast message to the user "We are going to shut down the server in X minutes/seconds, please, go out!". What do you think in doing something like that too?

I have no expirience with the signals neither but we must investigate.

[thasmo]

When on the server's console, one can shutdown the server cleanly by running c_shutdown(true). This tells the server to save the current world/session and then shuts down the server. I'm not sure the server stops cleanly otherwise, when the container gets stopped.

A broadcast message would be very nice, although it shouldn't delay the shutdown for too long. 10 seconds maximum and/or configureable.

Sending announcements is also possible from the console using c_announce("Announcement here.").

So, first we need to find out if the server cleanly shuts down if it gets a SIGTERM signal. And if not, we need to listen for it, and trigger a shutdown of the server. If we want to send a shutdown message anyway, we mandatorily need to trap the signal in all cases.

For the record, I'm not sure which signals are the proper ones. There's SIGINT, SIGTERM and SIGKILL any many others, which we probably do not need to take care of.

[thasmo]

Here's an example for trapping a signal: https://rimuhosting.com/knowledgebase/linux/misc/trapping-ctrl-c-in-bash

Another one: http://hacktux.com/bash/control/c

One more: http://redsymbol.net/articles/bash-exit-traps/

[BraisGabin]

I agree with you about the backup. We can write a paragraph about how to do a volume backup in the documentation.

About the --update... I'll prefer to enforce the image update. And I found a huge pro of this option: Your servers are much less time down.

docker pull dstacademy/server # the server is running while you are doing this!
docker rm -f dst_overworld
docker run [...] dstacademy/server

Your servers just stops to change the image. They have all the data already! Is more, you don't need to stop your servers if the pull say that you are up to date!

I'm not saying that we must not give the update option. We must give it. I'm saying that I don't want to give it too easy to use to try to enforce the other use. And for too easy I mean --update=[true|false]. I think that you had a TOO good idea :stuck_out_tongue:

[thasmo]

Basically, just for updating the game and mods (not the image) you can just do this: docker-compose restart or docker restart <container>.

Using docker rm -f <container> will probably kill your server without a proper save-game, so you will lose data, although it's the fastest.

Not so sure what you mean about my too good idea?! :D

[BraisGabin]

Yes, docker restart seems a much better option.

With too good Idea mean that I like it, it seems very handy. But I think that with a so much easy way less people would use the pull and restart way. And I think that the second one is better for the reason I gave before.

[thasmo]

Yeah, but I think it's two different things. Updating the game/mods is needed when a new version is released by Klei, so the server is compatible with all steam clients. The other thing is to update the image to get new fixes and/or features, but that's something totally different. People may want to use the same image as long as possible because upgrading the image could mean work. Work to update variables, volume paths, etc.

So we can not assume people will always update the image when a new game update is released, although I understand your thoughts and would also like to get people to update the images as often as possible.

[BraisGabin]

That's the problem. The image update must be completely painless. Just:

docker pull dstacademy/server
docker restart <container> or docker-compose restart

If we acomplish that we can try to promote that method. And I'm not thinking in our updates. If they want to stay in the v1.0 when we are at the v3.0 it's ok for me, that's their choice.

[thasmo]

docker restart <container> will not update the image for the container. Once a container has been started, the image will stay the same I believe.

So, the process to update the image and start new containers is:

docker pull <image>
docker-compose stop
docker-compose rm
docker-compose up -d

or

docker pull <image>
docker stop <container>
docker rm <container>
docker run <image>

For updating the game/mods it's enough to execute docker-compose restart or docker restart <container>.

[BraisGabin]

I researched a bit. With docker you must remove the image first as you say: https://github.com/docker/docker/issues/15725

But it seems that with compose upyou can make it easier: https://github.com/docker/docker/issues/15725

I didn't use compose yet so tell me what do you think. If you are not convinced yet I agree with add the --update flag.

Looking at the postgresql's entrypoint it seems handy for me give the option of compose start <container_id> bash or any other command you can imagine. The problem of this is how to avoid collisions between or three commands and the default ones. Any thoughts about this?

Any other command?

[BraisGabin]

We need a --help command too docker run dstacademy/server --help It show our different commands.

[thasmo]

When implementing this, we can probably also remove support for the variable UPDATE_ON_BOOT.

[BraisGabin]

What do you think if we change true and false for all and none

start --update=[all|none|game|mods]

[thasmo]

Already done that. See above. :)