https://gitlab.synchro.net/main/sbbs/-/commit/e532b58a066a21443c44d57e
Modified Files:
src/sbbs3/ftpsrvr.c mailsrvr.cpp main.cpp services.cpp websrvr.cpp
Log Message:
Servers incorrectely reported status of "Stopped" while recycling

They would briefly reported "Recycling" but then go to "Stopped" state - so if you tried to terminate sbbsctrl while a server was recycling, it would think it was already successfully stopped.

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

https://gitlab.synchro.net/main/sbbs/-/commit/884fe045cf80fd67ecd6e533
Modified Files:
src/sbbs3/ftpsrvr.c mailsrvr.cpp main.cpp services.cpp websrvr.cpp
Log Message:
Fix the race between recycle/reload and terminate/shutdown

When a server (any of the 5) saw that it had been requested to recycle, it would:

1. Set the server state to RELOADING
2. Do some shutdown stuff (close sockets, wait for child threads to terminate) 3. Call cleanup(0)
3a. which would (now) *not* set the server state to STOPPED (recent change)
3b. call the startup->terminated() callback (eh?)
4. Delay 2 seconds (with no explanation why)
5. Call the startup->recycle() callback (which usually reloads the sbbs.ini) 6. And then if the ''terminate_server'' flag had been set at any time after
step 1 (which is a long time now), it would just terminate the server
thread, leaving the state as RELOADING.

So,

- I removed the inexplicable 2 second delay (added in commit c1143ea077aca8f
"Recycles server on accept error")
- I moved the call to cleanup() to *after* the call to the startup->recycle
callback (which could take some time)
- I moved the calls to the startup->terminated() callback (which appears to
only be used by sbbsNTsvcs) to the if (terminate_server || code) conditional
block in cleanup()

The possibilty of a check of ''terminate_server'' racing with a request to recycle likely still exists somewhere, but I wasn't able to make it happen whereas it was easy to trigger the issue previous to this change. The race
was previously masked because we were always setting the server to STOPPED state while recycling (a different issue, previously fixed, which unmasked this issue).

A better fix would be to wrap each various server thread function in a
resource management function (or heck, a class constructor/destructor in the C++ servers) and not rely on the magic of the cleanup() functions being called at the right times in the right order with global state variables galore. But that's for another day.

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