https://gitlab.synchro.net/main/sbbs/-/issues/1178#note_9526
Some analysis of what this message actually means, and what we've changed:
## What the message is
`!Node N status with invalid socket corrected (was 3)` is logged by the terminal server's **connect** path, not the disconnect: a new caller scanning for a free node found one whose `node.dab` record still said in-use (3 = `NODE_INUSE`) even though no session/thread exists for it. The server self-heals the record and logs the discrepancy. So the disconnect you experienced wasn't just "unkind" — it was *unclean*: the node's normal teardown never got to reset its `node.dab` record, and the message you see later is the aftermath.
For what it's worth, the interruption itself (when a user is online at the start of an exclusive timed event) *is* the kind path — the node gets flagged for interrupt and the user is logged off gracefully. Whether users are forced off at all is your event's exclusive / "force users off-line" configuration.
## What we found and fixed
Two defects on master could strand the node record in-use:
1. The node thread's final status-reset gave up after a single failed locked read of `node.dab` — for example when the file is briefly locked or inaccessible right at maintenance time — and silently left the record in-use. It now retries, and logs an error if it still can't reset the record.
2. The exclusive-event force-disconnect (used only after a node ignores its interrupt flag for a full 60 minutes) closed the node's socket out from under the node thread, which also closes it during its own teardown — a cross-thread double-close. It now uses `shutdown()` to wake/disconnect the node and leaves the close to its owner.
The "corrected" message itself has been demoted from CRIT to ERR severity. It deliberately still lands in `data/error.log` — if it recurs after these fixes, that's a signal there's another unclean-teardown path we haven't found, and we'd like to know.
## If you see it again
Could you capture your terminal server log around the weekly-maintenance window and look for any of these lines?
- `!Interrupting node N` (the graceful kick)
- `!TIRED of waiting for node N to become inactive`
- `!TIMEOUT waiting for node N to become inactive`
- any `!ERROR ... node.dab` or `nodefile` lines
Those would tell us which path your node teardown took, and also whether your weekly event is configured exclusive / force-offline. Thanks!
— *Authored by Claude (Claude Code), on behalf of @rswindell*
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)