On Wed, Apr 13, 2022 at 6:04 AM Stefano B <
stefanoba...@gmail.com> wrote:
> Maybe in nodegame/conf is the least worst solution.
> About the best implementation in future releases, I need to understand the use case.
> What are you doing after SIGTERM? Simply shutting down?
Yes, using SIGTERM to shut down. The standard mechanism for bringing
services up and down and so on on Ubuntu (and many other Linux
distributions) is systemd. Its normal way of configuring things shuts
stuff down by
• sending SIGTERM
• waiting for the process it had started to stop
• then returning
If the process doesn’t stop in 90 seconds it then sends SIGKILL, which
is a pretty big hammer, not letting the process do an tidying. And,
also that 90 seconds is a long time to wait (especially compared to
the less than a tenth of a second it takes to start, which should be
the harder part :-) if all you’re trying to do is restart nodeGame to
make a small change to its configuration.
Note that if lancher.js took a command line option, say --mumble, that
told it to go ahead an honor SIGTERM, then systemd could be configured
to just start things using something like “node launcher.js --mumble”
and all would be well. I guess ideally nodeGame should be structured
in such a way (maybe it is already) that games could note SIGTERM and
do some tidying like closing databases and so on; or, even saying
“wow, someone is actually actively running this game please wait until
it’s done” — now even if all is quiescent and no one is actually
running a game it refuses to actually shut down, and we have to hammer
it with SIGKILL after 90 seconds which really doesn’t let anyone do
any cleanup at all.
The primary use case is restarting nodeGame to incorporate changes to
one or more of its games. The secondary use case is shutting down or
rebooting the host machine (which will wait until systemd tells it
nodeGame has stopped). The tertiary use case is other reasons we might
need to stop nodeGame, such as upgrading, changing its global
configuration, moving where the code is stored on the physical box,
stuff like that.
In principle systemd is sufficiently configurable we should be able to
make it do things differently than its default behavior, but I’ve not
been able to figure that out sufficiently to make it work well. Right
now I’m just shooting things with SIGKILL, which is always a little
iffy.
To give a little context, in the past, other folks in our lab found
the whole thing sufficiently difficult to understand that they’d each
just run their own instance of nodeGame using a different port,
running under their own terminal, and eventually killing it with ^C;
or nohupping it into the background, and trying to keeptrack of the
process number, or trying to look it up again later with pgrep or
something, so they could some back and kill --int it later, which many
times ended up with folks accidentally killing the wrong process and
making a mess of things. We’ve got a new physical server and I’m
trying to make the world simpler and tidier on it so folks only have
to move links in and out of nodegame/games/ and we don’t have to shoot
processes by hand and keep opening new ports in the firewall.
Hope that’s clear. Thanks!
--
Don Morrison <
d...@ringing.org>
“Human work must be done thoroughly and honourably because
we are now men; whether we ever expect to be angels, or ever
were slugs, being practically no matter.”
— John Ruskin, /Fors Clavigera/