Few questions/concerns/recommendations

[ich777]

Hi, in regards to this post on the Unraid forums I have a few questions/concerns about your container:

1. Are you running the server as root? If yes why? I would not recommend to run any application even in a container as root unless it is really required.
2. What happens when the server crashes in your container, from what I see the container will not stop even if the V-Rising server crashed or am I wrong?
3. Is .net and aspnet from Microsoft needed for V-Rising anyways, I have no issues running it without it and only through WINE
4. Do you stop the server properly, with SIGTERM or SIGINT, or is it killed after 10 seconds by the Docker (default timeout on Unraid) - keep in mind this could lead to a corrupt save file.
5. I'm not very familiar with Ubuntu but it shouldn't be much different to Debian (because I'm a Debian guy), usually the timezone should be set automatically to the correct one by Docker, even if not it should be enough that you create a Environment variable eg: TZ=Europe/Vienna like in my container.
6. In your README.md you are having a section about changing the ports, I would not recommend to use Steam ports as a example, because well they are usually reserved for Steam things (27015-27030).
7. Why are you pointing tail to the file /var/log/dpkg.log and not to the V-Rising server log?
8. Do you have a way of passing UID/GID or PUID/PGID to the container?

Many Regards, Christoph

[TrueOsiris]

• [x] 1. I'll test with removing this. (edit: figured it out where this came from. I have copied the initial Dockerfile from trueosiris/git from where I build my containers. it has my own DinD system, for which I need either root or priviliged access on my host.)
• [ ] 2. Normally, when the wine64 command tanks, the container should stop. I left the tail inthere to debug. Zero issues yet with servercrashes, so that tail is a redundant line.
• [x] 3. The dotnet section can be omitted. That's still inthere as I started from an older container that ran a dedicated server of another game with several specific dlls. I'll remove it.
• [ ] 4. I have no idea how I would pass that interrupt on on docker stop. Feel free to enlighten me.
• [x] 5. The base image of debian and ubuntu don't differ much, imho. The timezone fix I did with several containers. On some platform it works with just passing the TZ, on others it doesn't. I reacted to a reported issue and applied the fix that works for all. It's indeed an ubuntu container issue.
• [ ] 6. ah, those example ports were also a reaction on a question. I'll alter them to something more generic.
• [ ] 7. that tail was just there to keep the container alive should the exe crash. Hasn't happened so far.
• [ ] 8. Not yet. could implement that.

Thx for the reply. I'll get cracking. On your question on 'which issues' I've overcome -> the TZ, the issue with the xvfb not stopping, and some others.

[ich777]

• 1. Can't remember exactly why I did this. Has to do with the exe creating folders on a dockerhost volume with not enough rights. I'll test with removing this.

It is never recommended and of course not best practice to run anything as root in a container. If a user has too less rights on the folder where Docker tries to write into then the installation from this user is messed up anyways, it is always up to the user to ensure that the folder where the Docker container wants to write into has the right permissions.

Non or at least no container from me is designed to run as root and also can't run as root (as long as you don't write a really good user.sh and mount it to the container). Actually that's not entirely true for a hand full because they need to be root or requires it sometimes so that the application can run as root but that is changeable by a variable.

• 2. Normally, when the wine64 command tanks, the container should stop. I left the tail inthere to debug. Zero issues yet with servercrashes, so that tail is a redundant line.

But I would strongly recommend that you write a watchdog script or something that checks if the server actually runs, for example if a user starts the container with the wrong settings for V-Rising, the V-Rising server can instantly crash and the container won't restart/stop because the last process that is started was tail, I think you get the point.

• 4. I have no idea how I would pass that interrupt on on docker stop. Feel free to enlighten me.

I'll catch for example the stop command from Docker here and then send a SIGINT or SIGTERM to the appllication and wait for it to gracefully exit.

I reacted to a reported issue and applied the fix that works for all. It's indeed an ubuntu container issue.

Yes, already saw that Issue... :smiley: I can only tell you that you can pass over a Environment variable in my containers (this worked since Debian Jessie?) like mentioned above eg: TZ=Europe/Belgium

• 6. ah, those example ports were also a reaction on a question. I'll alter them to something more generic.

A little bit more on this from my side, I won't recommend this because strictly speaking Steam "reserves" this ports and some games won't even run properly if you use other ports not within that range.

• 7. that tail was just there to keep the container alive should the exe crash. Hasn't happened so far.

In my templates on Unraid I use --restart=unless-stopped in the Extra Parameters so that the container actually restarts if it crashes or if someone wants to restart it from the console if no restart command in the game is implemented (this was also a reaction to a user issue and this worked actually good in my containers.

the issue with the xvfb not stopping, and some others.

Is this also the case in my container? I've never had such issues so far in my container. I only had a few issues with users that are running the container an AMD platforms with cryptographic errors but that fixed somehow itself after a server reboot which is very strange and I really can't tell why or even how this is possible...

Hope that explains a bit more and/or helps.

[Alaith]

For proper shutdown handling, I believe that if you exec wine64 at the end of your start.sh entry script the signals will get passed to wine (and the vrising server) properly. Right now the signals are passed from docker to your entry script, but not forwarded to wine, xvfb, etc.

That would mean the entry script will never make it to your tail command, but this shouldn't be a problem if we just stop the server from writing its logs to a file, and instead have it write logs to stdout to begin with (the default when no -logFile flag is passed). Edit: I just noticed you say the tail is there to "catch" the container from stopping if the server crashes. I would rather Docker restart the container in event of a crash by having restart: unless-stopped in my docker-compose service configuration.

I have a question about xvfb. Is it necessary? I see that there are some wine containers around which specifically compile wine without X (ie: muojp/docker-wine64). If xvfb can be removed as a dependency, then using exec in your entry script to start wine further improves the shutdown handling.