https://gitlab.synchro.net/main/sbbs/-/commit/74724d0b83150c1da1a88d74
Modified Files:
src/sbbs3/main.cpp
Log Message:
When searching for unused nodes, skip nodes that have sockets in-use

We already know such nodes are in-use, so no need to read their node.dab
record and put extra contention on the node.dab file. Hoepfully this
reduces or eliminates occurrences of the error:
Node n status is WFC, but the node socket (s) and thread are still in use! Though I kind of expect occurrences of "NODE STATUS FIXUP" errors to likely return.

We could in theory just track status of nodes in memory (for those
nodes that this instance of sbbs controls), and not read the node.dab file at all when checking those nodes' status, but:
- that would prevent out of process control of node status
e.g. using the node utility to mark a node as offline
- we'd have to protect instance of in-memory node status checking/changing
with a mutex

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

https://gitlab.synchro.net/main/sbbs/-/commit/a4f032b82ed2ddfbd23e963d
Modified Files:
src/sbbs3/main.cpp
Log Message:
Fix-up node status when node status is in-use, but no socket active

This is a situation we can auto-correct and log a message when we do.

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

https://gitlab.synchro.net/main/sbbs/-/commit/2d487931e40d312071024416
Modified Files:
src/sbbs3/main.cpp
Log Message:
Fix race conditions around node_socket and node.dab checks

Check and clear/invalidate node_socket while holding the node.dab record
lock.

This should fix the error reported by kk4qnb (KK4QBN)

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

https://gitlab.synchro.net/main/sbbs/-/commit/480598355c061c7a3507f24e
Modified Files:
src/sbbs3/main.cpp
Log Message:
Continue the "ERROR ... renaming" bad QWK packet fight

Check and log the length of the packet now (since fexist() continues to report that the file exists when fexistcase() said it did not, even when
experimenting with adding a call to access(filanem, F_OK).

This likely affects no system but VERT.

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

https://gitlab.synchro.net/main/sbbs/-/commit/e4e41db746c18c1bab6a0083
Modified Files:
src/sbbs3/main.cpp
Log Message:
Don't create (or write) to qnet.dab, so open with right access

We're just converting/upgrading this file (to time.ini), so don't log an error (reading) if/when the file doesn't exist.

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

https://gitlab.synchro.net/main/sbbs/-/commit/d06e2f27e7f3862cf049bc6a
Modified Files:
src/sbbs3/main.cpp
Log Message:
Add another flength() check before renaming bad QWK packets

To hopefully address:
!ERROR 2 (No such file or directory) renaming s:\sbbs\data\file/somenum.rep
(-1 bytes) to s:\sbbs\data\file/somenum.rep.6777ed7c.bad

Clearly flength() is returning -1 (file doesn't exist) at this point, so perhaps the call to fremove() just above updated a cached directory?

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

https://gitlab.synchro.net/main/sbbs/-/commit/3bf096b52465792776df3787
Modified Files:
src/sbbs3/main.cpp
Log Message:
Make JS global alert() and deny() methods inline with jsexec versions

alert() doesn't throw exception on null/undefined, just no arg

deny() throws exception on no args or null/undefined arg

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

https://gitlab.synchro.net/main/sbbs/-/commit/64352121b6727a90eee5e848
Modified Files:
src/sbbs3/main.cpp
Log Message:
Don't attempt to remove inbound QWK packet if doesn't exist (renamed?)

Address error report by Greg Meckel (THEICECA)
evnt QNET !ERROR 2 (No such file or directory) (EinError 2) in main.cpp line 3195 (event_thread) removing "C:\sbbs\data\VERT.qwk" access=0

... this could happen after a bad QWK packet was detected and renamed.

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

https://gitlab.synchro.net/main/sbbs/-/commit/6a0971f6e79ec18c2ed611dc
Modified Files:
src/sbbs3/main.cpp
Log Message:
filelength() can return -1 on error, deal

Just caught during code review

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

https://gitlab.synchro.net/main/sbbs/-/commit/0ac5ed5728c53d93eb347c23
Modified Files:
src/sbbs3/main.cpp
Log Message:
Set node "interrupt" flag to try to gracefully disconnect user blocking event

When a timed event is configured to run "exclusively", all nodes need to not be in in-use. As it was, after waiting 60 minutes for the online user(s) to
notice they'd run out of time and disconnect, we'd just (rather ungracefully) close the sockets used by such node(s) connections. This results in same logged errors about trying to send to bad socket descriptors and provides no feedback to the user about why they were disconnected.

Since we have the node interrupt flag (which hopefully, all scripts are checking via node_sync) - use that to try to more gracefully terminate the user's session/connection after 30 minutes of waiting for the user to disconnect.

If after 60 minutes of waiting, the node is still in-use, we still do the socket disconnection method.

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

https://gitlab.synchro.net/main/sbbs/-/commit/aea882a8e4552b64c03c521d
Modified Files:
src/sbbs3/main.cpp
Log Message:
Initialize Terminal in global sbbs when answering

Should fix issue where extra pauses occur on connection.

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

https://gitlab.synchro.net/main/sbbs/-/commit/f218ad1fec992a71f590120e
Modified Files:
src/sbbs3/main.cpp
Log Message:
Fix typo (thrad->thread)

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

https://gitlab.synchro.net/main/sbbs/-/commit/3073a9a3503a3961912a54c2
Modified Files:
src/sbbs3/main.cpp
Log Message:
Add and improve log messages (warnings, errors) in input_thread()

... mainly to help understand (still a mystery) how the first check of
the inbuf free space could pass (there's at least one byte available), but
the second check (after recv()) fail and the "INPUT BUFFER FULL" message gets logged - that doesn't seem possible unless there's some other thread stuffing chars into the inbuf (and that shouldn't be happening with the exception of node spying).

While investigating this mystery, I saw there missing node numbers and other helpful data (e.g. the number of bytes received to that point) from some of
the log messages. And in some SSH error conditions, nothing would be logged though the input_thread's loop would terminate (break), so added some log messages for "Operation complete" and "Timeout" which had explicit handlers with no log output.

Increase the received byte counter from 32 to 64-bits.

Stop using the 'rd' varible for multiple purposes, improving readability.

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

https://gitlab.synchro.net/main/sbbs/-/commit/3a2790c7d3e538cd27404feb
Modified Files:
src/sbbs3/main.cpp
Log Message:
Immediately abort the event_thread() if started with server terminated

Resolve this crash that happens when aborting startup while trying to bind
TCP ports:

Thread 11 "sbbs/events" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff1dfc6c0 (LWP 13543)]
js::gc::Chunk::init (this=0x7fffeb600000, rt=0x7fffe0019120) at jsgc.cpp:293 293 arena->header()->next = arena + 1;
(gdb) bt

Not root-caused, just worked-around/avoided. Most likely there's a js cleanup happening (e.g. destroying the JS runtime) the same time that js_init() is executing from the event_thread(), so just avoid this by not calling js_init() while already set to terminate the server.

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

https://gitlab.synchro.net/main/sbbs/-/commit/b7d3db6c3e57e75f3ee36569
Modified Files:
src/sbbs3/main.cpp
Log Message:
Revert write_raw() back to direct, unprocessed, output

deon (ALTERANT) reported an issue with his Viewdata terminal support after upgrading from v3.19 to the latest code in git. He's using JS write_raw() to send viewdata sequences to the remote terminal.

I'm not sure why Deuce changed write_raw() from calling putcom(), but let's try reverting back to using putcom() to see if that resolves the reported issue
and whatever objection Deuce may have.

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

https://gitlab.synchro.net/main/sbbs/-/commit/70480dcee4378c21be0ca536
Modified Files:
src/sbbs3/main.cpp
Log Message:
Add some passthru thread debug log messages

To hopefully help identify the cause of issue #1038

The theory being that the client socket was disconnected while running an external program (sexyz in this case) and this check at the end of external() (the *nix version) might have a race condition with the passthru thread terminating due to disconnection as well:
if (!(mode & EX_STDIN)) {
if (passthru_thread_running)
passthru_socket_activate(false);
else
pthread_mutex_unlock(&input_thread_mutex);
}
in which case it would try to unlock the input_thread_mutex that it did not own. I'm not clear why that would cause the pthread_mutex_destroy() call to fail (on input_thread_mutex) but maybe it does.

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

https://gitlab.synchro.net/main/sbbs/-/commit/7e7db957384647c44958d0cb
Modified Files:
src/sbbs3/main.cpp
Log Message:
When upgrading a legacy time.dab to new time.ini format, ignore unreadables

It's possible the configuration was upgraded (e.g. by update.js) before any timed events have run, so the time.dab could be short. Just zero-initialize (and don't log any errors) if there's trouble reading a legacy timestamp from time.dab or qnet.dab.

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

https://gitlab.synchro.net/main/sbbs/-/commit/f21adb001964358bc95c1e28
Modified Files:
src/sbbs3/main.cpp
Log Message:
Defeat the extra lines goings to the events.log file

Example:
2026-01-06 23:59:59 BBS Events New Day - Prev: Wed Jan 07 2026 12:00 am
!= New Day - Prev: Wed Jan 07 2026 12:00 am

In theory this cold happen while a user was logging on, hence the use of llprintf()->logline(), but we don't want that redundant noise in the
events.log file so we have to play a dance with 'online' value.

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

https://gitlab.synchro.net/main/sbbs/-/commit/7e8760ce6ef8c60051202ef0
Modified Files:
src/sbbs3/main.cpp
Log Message:
Don't backup empty user bases or mail bases

Address "it seems silly to have five backup empty mail files too" comment
in issue #993.

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

https://gitlab.synchro.net/main/sbbs/-/commit/f66c37792f6027f1b1cdd06f
Modified Files:
src/sbbs3/main.cpp
Log Message:
Log the number of users and mail messages that were included in the backups

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

https://gitlab.synchro.net/main/sbbs/-/commit/6f4dac2d037978d0c92dfa7f
Modified Files:
src/sbbs3/main.cpp
Log Message:
Remove hyphen from "Backing-up" and "Backed-up" log messages

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

https://gitlab.synchro.net/main/sbbs/-/commit/674c4facfbfcd5855915ade5
Modified Files:
src/sbbs3/main.cpp
Log Message:
Fix (new) bug caught by GCC printf verifier

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

https://gitlab.synchro.net/main/sbbs/-/commit/b9e11d2fd2a13154b382f5a0
Modified Files:
src/sbbs3/main.cpp
Log Message:
Fix accidental recursion in sbbs_t::backup()

Bug introduced in commit 39e1c58ad631baea289349eb02

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

https://gitlab.synchro.net/main/sbbs/-/commit/372404c4f6491a962cbd9471
Modified Files:
src/sbbs3/main.cpp
Log Message:
Don't try to validate the userbase if it doesn't exist

Fix for new installs as reported by Storm on IRC (thank you)

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

https://gitlab.synchro.net/main/sbbs/-/commit/a401004cd4401616a2a2312f
Modified Files:
src/sbbs3/main.cpp
Log Message:
Remove debug log line inadvertently left in

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

https://gitlab.synchro.net/main/sbbs/-/commit/8b6210dcaf2e3b49ed16f110
Modified Files:
src/sbbs3/main.cpp
Log Message:
Destroy the nodefile_mutex in sbbs_t destructor

This could've been a small memory leak

Also using [F]CLOSE_OPEN_FILE function-like macros to simplify code

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

https://gitlab.synchro.net/main/sbbs/-/commit/819d26b6c593606c3e2e2497
Modified Files:
src/sbbs3/main.cpp
Log Message:
Simplify/correct the node status fixup upon client connect

- when we treat a non-WFC node status the same as WFC because the node_socket
is invalid, don't call lprintf(LOG_CRIT, ...) with the node logged. That's
ultimately going to call errormsg() which is going to try to increment the
node's critical error counter and fail or deadlock because the node's
record is already locked. Log the error after we call putnodedat() and the
node record has been unlocked.
- The "status is WFC" while the node_socket is valid check would always fail
because we already checked the node_socket validity at the top of the loop
so just remove this check/error message as dead code

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

https://gitlab.synchro.net/main/sbbs/-/commit/80137a5129d974935681c478
Modified Files:
src/sbbs3/main.cpp
Log Message:
Log the corrected node status value (error caught be GCC printf-validation)

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

https://gitlab.synchro.net/main/sbbs/-/commit/5c099d90d119dd447133160b
Modified Files:
src/sbbs3/main.cpp
Log Message:
Replace break accidentally removed in previous commit

Would mark all nodes as at the prompt up new connection (big whoops)

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

https://gitlab.synchro.net/main/sbbs/-/commit/783473d285db5e03b445a9fb
Modified Files:
src/sbbs3/main.cpp
Log Message:
Correct node status stuck in "logout" status too (abnormal condition)

"LOGOUT" is another node status where the socket should be valid

Since my Debian 13 (and Samba) upgrade, I've been getting a lot of node.dab
and mail base corruption. Some of these conditions can be auto-corrected and this is one of them.

Removed some obsolete comments about old crash reports.

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

https://gitlab.synchro.net/main/sbbs/-/commit/43328cad606fde38aec86eea
Modified Files:
src/sbbs3/main.cpp
Log Message:
Fix potential socket leak upon server termination

caught/reported by Claude via Deuce

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

https://gitlab.synchro.net/main/sbbs/-/commit/6e49cb9c959c7e1710a1ac09
Modified Files:
src/sbbs3/main.cpp
Log Message:
Coverity complained about this unnecessary invalidation of client_socket here

CID 644869

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

https://gitlab.synchro.net/main/sbbs/-/commit/b598dcbb541ca8ddf8a083d8
Modified Files:
src/sbbs3/main.cpp
Log Message:
Insure all alert() output begins in the first (left-most) column

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

https://gitlab.synchro.net/main/sbbs/-/commit/ff1aae498b3464b1f2fd050a
Modified Files:
src/sbbs3/main.cpp
Log Message:
sbbs3 terminal server: drop unsent goodbye output before close_socket

In the four listener exit paths that queue output via the listener
pseudo-sbbs (CLIENT BLOCKED for ip.can / host.can, "no nodes
available", node init failure), call sbbs->rioctl(IOFB) right after flush_output() and before close_socket(). Without this, any
text/badip.msg / badhost.msg / nonodes.txt residue that didn't make
it out within the flush timeout sits in the ring buffer; when the
output thread next wakes it tries to send the leftover on the
now-closed FD, and the failed send logs a noisy warning (e.g.
"!ERROR 22 (...)" or "!ERROR 58 (...)" sending on socket).

This is the same idiom as the existing rioctl(IOFB) at the start of
the per-connection setup (main.cpp:5795) Ä purge stale buffer state
before changing socket lifecycle.

It does not eliminate the race entirely: data already pulled from
the ring buffer into the output thread's linear buffer is still sent
(or attempted), since rioctl operates on the ring buffer only. The
remaining noise is handled separately by demoting the typical
post-shutdown send errors (ESHUTDOWN, EINVAL) to LOG_NOTICE.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

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

https://gitlab.synchro.net/main/sbbs/-/commit/8c6da8b2eee4363c1fcb9925
Modified Files:
src/sbbs3/main.cpp
Log Message:
sbbs3 terminal server: include socket/protocol/IP in output_thread send-error logs

Three coordinated changes to output_thread's SOCKET_ERROR handling:

* Switch all six log lines from "<node-name> ..." (using sbbs->client_name
like "Terminal Server" / "Node N") to the standard "%04d %s [%s] ..."
prefix used by every other connection log line in the file. This
groups send errors with the matching "Connection accepted",
"!CLIENT BLOCKED", etc. lines for easy correlation. Capture
client_socket.load() once into a local since the cascade reads it
six times (it's std::atomic).

* Populate the listener pseudo-sbbs's client.protocol and client_ipaddr
per-connection. These were previously only set inside sbbs_t::init()
for per-node sbbs's (main.cpp:3639), leaving the listener's
output_thread with empty strings to print.

* Demote ESHUTDOWN and EINVAL send errors to LOG_NOTICE alongside the
existing ENOTSOCK / ECONNRESET / ECONNABORTED handlers. Both are
the typical errors raised when the listener races with close_socket()
on a blocked client (post-shutdown / mid-close socket state).
Treating them as expected disconnect noise matches the existing
pattern. Note: on POSIX, EINVAL from send() can theoretically
indicate a programming bug rather than a socket-state race, but in
practice it's the same race as on Windows and the noise reduction
is worth the small risk of masking.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

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