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.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/f78a70986d1e3b21b09ca32e
Modified Files:
src/sbbs3/xtrn.cpp
Log Message:
Fix name of data event

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/76fa22e427a7b9978084bf94
Modified Files:
src/sbbs3/xtrn.cpp
Log Message:
Remove lprintf() call from child process of fork() call on *nix

the info-level debug message "Detaching external process"... as this appears
to be the cause of background events hanging sometimes, on Linux (at least).

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/fd2a8b605803259ceb974d49
Modified Files:
src/sbbs3/xtrn.cpp
Log Message:
Add node interrupt flag checking to *nix external() execution of stdio progs

and abort the execution of the program when the node is interrupted. This should allow more cases were the node interrupt flag can be used to gracefully disconnect a user running a DOS or native (stdio) program on *nix.

We have this functionality already in the Windows version of external()

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/35d530c3a4eccd6b2ed1964b
Modified Files:
src/sbbs3/xtrn.cpp
Log Message:
Disable pause when running an external program.

Not sure if this is from the terminal overhaul or from the unicode
support, but passthru_thread calls rputs() which calls cp437_out()
which calls outchar() which calls check_pause().

Also, put an EINTR wrapper around waidpid()... that wasn't the
problem I was seeing, but it's a theoretically possible one.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/47e263f1e72073e9488db9f8
Modified Files:
src/sbbs3/xtrn.cpp
Log Message:
Remove unneeded debug logging.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/00d24f1bfc0f8e2f5453579f
Modified Files:
src/sbbs3/xtrn.cpp
Log Message:
Revert "Disable pause when running an external program."

This reverts commit 35d530c3a4eccd6b2ed1964bf21cbcf9237da721.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/3f97c2713305442a55035063
Modified Files:
src/sbbs3/xtrn.cpp
Log Message:
Fix error in 35d530c3a4e

Instead of looping while waitpid() returned an error due to a signal,
it was looping *until* waitpid() returned an error due to a signal.

This could cause an infinite loop on *nix systems after an external
exited if waitpid() was returning an error for some other reason.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/26904b5dc456d76dc1b0ec29
Modified Files:
src/sbbs3/xtrn.cpp
Log Message:
Only attempt to unlock the input_thread_mutex if we previously locked it

This *might* fix issue #1038

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/5d43eed990eda19d808d8c92
Modified Files:
src/sbbs3/xtrn.cpp
Log Message:
Don't use dosemu paths in command-lines when dosemu support is disabled

This just adds to confusion when debugging weird errors, like this:

pack_qwk.cpp line 753 (pack_qwk) executing "H:\zip -jD /sbbs/data/file/0230.qwk

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net