Subj : src/sbbs3/xtrn.cpp
To   : Git commit to main/sbbs/master
From : Rob Swindell
Date : Fri Oct 07 2022 06:42 pm

https://gitlab.synchro.net/main/sbbs/-/commit/e7109c87bc43f21636c5f981
Modified Files:
	src/sbbs3/xtrn.cpp
Log Message:
When user hangs-up on external programs on *nix, try to terminate w/SIGTERM

Previously, when a user disconnected or ran out of time while running a
stdio-based external program on *nix, if the program was still running, we'd
send it a SIGHUP, wait up to 10 seconds for the process to terminate and if
it did not, terminate it (ungracefully) with SIGKILL. Since some programs
catch SIGTERM (and not SIGHUP) to indicate a termination request, we now will
first attempt a SIGHUP, wait up to 5 seconds for the process to terminate and
if it does not, then send a SIGTERM and wait up to another 5 seconds for it
to terminate and if it doesn't, then finally send it a SIGKILL (which cannot
be caught and always results in an ungraceful termination of the child
process).

This doesn't resolve any specific problem with any specific stdio-based
external program, but I was playing around with ESR's port of Adventure
(https://gitlab.com/esr/open-adventure) and a new auto-save/restore of game
state and noticed that we weren't using SIGTERM for this situation, though we
should have. Most modern programs, if they catch SIGHUP at all, use it to
indicate a refresh of configuration or data files, not a termination request
(or indication that a user has "hung up"). So SIGTERM is more reasonable to be
expected to be caught and initiate the graceful termination of the child
program that we're hoping for.

.