Use SIGINT for server shutdown about valheim-docker

[mbround18]

For the pid, I don't support running multiple servers in one container and currently it returns the pid if the main process.

I'll check outputs in a little bit

[spion06]

looks to work for me! I do have some issues with the entrypoint.sh actually triggering the exit trap on kubernetes. I think if you were to change https://github.com/mbround18/valheim-docker/blob/main/src/scripts/init.sh#L74 to do an exec it would behave as expected.

[Shuro]

I tried to come with a way to send SIGINT to the docker container, noticing that it also saves the wrong PID in the pidfile.

Needs to be adressed in src/files/start_server_rusty.rs.

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root       148  0.0  0.0   3992  3344 pts/0    Ss   16:22   0:00 /bin/bash
root       466  0.0  0.0   7640  2772 pts/0    R+   16:29   0:00  \_ ps auxf
root         1  0.0  0.0   3736  2912 ?        Ss   16:09   0:00 /bin/bash /init.sh
root        37  0.0  0.0   6164  2628 ?        S    16:09   0:00 su -ps /bin/bash --login steam -c /bin/bash /home/s
steam       38  0.0  0.0   3652  2720 ?        Ss   16:09   0:00  \_ /bin/bash /home/steam/scripts/entrypoint.sh
steam       97  0.0  0.0   2328   752 ?        S    16:09   0:00      \_ tail -f /home/steam/valheim/output.log
steam       94  163  1.2 8477648 1713216 ?     Rl   16:09  31:27 /home/steam/valheim/valheim_server.x86_64 -port 245
steam       95  0.0  0.0   2300   684 ?        S    16:09   0:00 tee ./output.log
root@099cacafa16c:/home/steam/valheim# cat valheim_server.pid
95
root@099cacafa16c:/home/steam/valheim#

[mbround18]

Good call out, ill take a look at putting in a fix for this today

[mbround18]

Fix for this is live on :latest and working on my production servers. Would someone mind giving it a whirl to confirm?

[Shuro]

not familiar with rust, but the output of pidof should be without any new lines, so the replace would be unneccesary. It could be problematic if there are multiple processes tho.

Example:

[Shuro]

Tested it with my production server and it didn't seem to work out.

Left: Stopped container, pulled newest image, started, waited and stopped.
Right: docker-compose logs -f output after start.

shuro@mainframe ~/games $ docker images |grep valheim
mbround18/valheim               latest            5d4d0159a7b0   18 minutes ago   791MB
mbround18/valheim               <none>            ff710c1307b9   23 hours ago     791MB
mbround18/valheim               <none>            d1af17770c8d   45 hours ago     802MB

[mbround18]

@Shuro tossed up #38 which handles if you decide to run multiple processes. It finds it by name and sends SIGINT via rust rather than using the operating system commands.

[mbround18]

Great minds think alike :P I am actually writing that bit right now

[Shuro]

Got the following now:

Pulling valheim ... done
(reverse-i-search)`u': docker-compose p^Cl
shuro@mainframe ~/games $ docker-compose up -d
Building with native build. Learn about native build in Compose here: https://docs.docker.com/go/compose-native-build/
Creating games_valheim_1 ... error

ERROR: for games_valheim_1  Cannot start service valheim: OCI runtime create failed: container_linux.go:370: starting container process caused: exec: "/init.sh": permission denied: unknown

ERROR: for valheim  Cannot start service valheim: OCI runtime create failed: container_linux.go:370: starting container process caused: exec: "/init.sh": permission denied: unknown
ERROR: Encountered errors while bringing up the project.

Fixed it temporary by adding the entrypoint /bin/bash /init.shto the docker-compose

[mbround18]

Hey @spion06 when I added the trap to the init it doesnt seem to shutdown the server correctly it still exits with 137

[spion06]

yeah that's most likely due to su swallowing it. gosu might be a better option here https://github.com/tianon/gosu. There's also su-exec. I've seen both used in docker containers for similar problems

[mbround18]

#39 Hmm I added gosu and the exit coming out is still 137... I will have to do some more digging on this

[Shuro]

Yes, looks fine now. Exiting with cod 143, which means all is fine (SIGTERM was sent to docker container).

@mbround18 Only suggestion from my side. Stop via odin first and then kill the tee? 😅
This way you could confirm the log entries for saving the world, etc, which are lost if you kill tee first.