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.

Per Deon (ALTERANT) via DOVE-Net:

Oct  7 09:47:16 d-11-1 synchronet: srvc 0060 BINKPS connection accepted from:
2402:1f00:8101:b3c:1000::2 port 55338
Oct  7 09:47:16 d-11-1 synchronet: srvc 0060 BINKPS TLS ERROR 'Server
certificate has expired' (-3) setting private key
Oct  7 09:47:16 d-11-1 synchronet: srvc 0060 BINKPS TLS ERROR 'Data has not
been initialised' (-11) setting session active

Which was odd, because my cert was renewed.

I forced renewed it, and confirmed it was valid, but they were still failing.

I noticed that letsyncrypt only recycles the web, which is probably the issue.
Once I recycled everything, binkps connections started working again.

BINKP is suddenly frequently hanging on sendsocket() on Vertrauen on Windows
(sending files to my Z1 hub) so try this as a solution.

Fixes #401

Fixes #368

DDMsgReader: Added a mouse click hotspot for ? for message list mode

See merge request !210

DDMsgReader: Refactored how email replies are done (passing the header to the appropriate functions, not using ungetstr() when prompting for the message subject

See merge request !209

Eric Oulashin authored 2 years ago and Rob Swindell committed 2 years ago

DDMsgReader: Refactored how email replies are done (passing the header to the appropriate functions, not using ungetstr() when prompting for the message subject

Need to nullify the xpms after destroying/freeing (as is done in other
servers already).

Removed temporary debug code that accidentally made it in last commit

See merge request !208

Sometimes files uploaded may have the wrong case in the filebase (a different
unresolved issue), but for instances where that has happened, make those files
viewable in sbbs. This really only impacts target OSes with case-sensitive
file systems (e.g. *nix).

As reported by Android8675 (SHODAN) on DOVE-Net.
This problem did not manifest itself in 32-bit builds.

If a new JS context could not be created for any reason, a JS runtime would
still be allocated (and leaked), potentially leading to out of memory
situations which had been seen (before this change) on vert.synchro.net.

Set the control key pass-thru so that some hotkeys (such as Ctrl-P for PageUp) only get caught by the scripts.

See merge request !207

Set the control key pass-thru so that some hotkeys (such as Ctrl-P for PageUp) only get caught by the scripts.

The "Events" log messages will now be logged to a disk file in
data/events*.log by default (unless this option is disabled).

If the "First node" is > 1, then the base filename will be
"events<first-node>", otherwise, it's just "events". This is because you
would not want multiple instances of sbbs writing to the same events.log
file - that would be chaos. These log files are subject the log
rotation/retention policy defined in SCFG.

This should resolve the FAQ for Windows sysops about what log file to
which their event log messages are being written.

The functions aren't DLL-exported, so the difference in FILE* support
between an app and a library is not an issue... yet, but it could be
someday, so just for good measure.

Also, don't match against deleted (blank) usernames in name.dat
(e.g. when 'name' value consists of a single ETX character).

Proper use of js.on_exit() in DDMsgReader and SlyEdit

See merge request !206

Used js.on_exit() to set console.ctrlkey_passthru back on exit properly (SlyEdit, DDMsgReader) and bbs.sys_status (SlyEdit)

DDMsgReader v1.54: Users now have a personal twit list (configurable via Ctrl-U, user settings).

See merge request !205

When there are no chat action sets or an action set has been deleted, bad
things would happen (e.g. segfault) when listing chat channels.

To be more consistent in syntax and include more details (e.g. the command
being invoked).

Address issue reported by Nightfox via DOVE-Net:
Today I was using the Archive class to extract exactly one file from a zip
file, and I'm a little confused on the exception throwing behavior regarding
the max_files parameter.  When calling extract(), I gave it a filename pattern
and expected exactly 1 file to be extracted, so I also gave a max_files
argument as 1.  It extracted the one file, but it threw an exception with the
error "Error: maximum number of files (1) extracted (after extracting 1 item
successfully)".

Should that be an error condition to throw an exception? I expected 1 file to
be extracted, and that file was extracted successfully.  If I specify max_files
as 2, then it doesn't throw an exception.   

Local sysop can always deleted/edit entries (now).
Fixed checking of can_edit() return value (string or true), fixed issue #425
as reported by Craig Hendricks (thank you)