Closed Oldsouldier closed 1 week ago
Another possible explanation of why this works better is that the wait
at the bottom of launch.sh
is interrupted by the signals received (once exec
was added to entry.sh
), so the 1 second sleep was not enough wait for the process to shut down prior to the container terminating. The additional wait
in the trap handler provides the necessary delay.
Hello @Oldsouldier, thank you for the PR. Yesterday we merged a PR adding tini for passing signals, thanks to @solareon
Doesn't that solves this issue?
What do you think GOAT @Micke90s ?
@arguser It was part of the solution, but does not produce the desired outcome. I added echo
statements in the trap handler in launch.sh
and they were not printing until i added the exec
call in entry.sh
.
Furthermore, even after the signal was being caught, i noticed loss of progress when shutting down due to the wait
call being interrupted by the signal (my current theory). This is a known behavior of wait
. The additional call to wait
allows time for a complete shutdown, which is the entire point of the signal passing in the first place.
@Oldsouldier: Thank you for the detailed explanation and your pull request. Works perfect :+1: Just saw that the server even would wait for the last player to leave before stop.
This fully completes the passing of docker shutdown signals to the game executable. (Completes #46) Prior to this, the signals were not being passed from
entry.sh
tolaunch.sh
. Another alternative is to merely sourceentry.sh
fromlaunch.sh
and makelaunch.sh
the actual dockerfile command.Also, after some testing, i noticed some lost progress when shutting down the world. Delaying the termination of xvfb by
wait
ing within the trap handler seemed to eliminate this problem for me.