https://gitlab.synchro.net/main/sbbs/-/commit/1581ed4b45b9f6d6ef7c63d7
Modified Files:
src/sbbs3/ftpsrvr.c mailsrvr.c main.cpp services.c websrvr.c
Log Message:
Use protected_int*_adjust[_fetch]() correctly

At least on Linux/GCC, std-atomic version of xpdev/protected_int API was only used when building .cpp files and the _adjust() functions returned a different value from the .c files since they used the mutex versions of these functions/ macros. Use the _adjust_fetch() versions of the API when the return value is used (and assumed to be the *new* / adjusted value of the integer).

It's possible for other tool-chains or target platforms, the .c usage was
wrong as well (assuming the *new* integer value was returned rather than the old), if they built with std-atomic support for C.

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

https://gitlab.synchro.net/main/sbbs/-/commit/1ec7cb53a8f52df12d6623e7
Modified Files:
src/sbbs3/ftpsrvr.c mailsrvr.c main.cpp services.c trash.c trash.h websrvr.c
Log Message:
Support a filter (*.can) file 'quiet' attribute (e.g. "q=1")

A dubious feature. This will squelch any "CLIENT BLOCKED" type log messages assocated with a filtered client. Importantly, other log messages related to the client connection won't be (can't be) squelched, so this isn't going to really be a useful feature in my opinion, but when sysops ask for this (e.g. silently-blocking specific hostnames), I want to be able to demonstrate why that's not really practical.

The syntax is "<filter-string><tab>q=1" if you want to play with it.

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

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