TZUTC: -0800   
   MSGID: 54336.syncprog@1:103/705 2de7807d   
   PID: Synchronet 3.21b-Linux master/5c73d262c Jan 21 2026 GCC 12.2.0   
   TID: SBBSecho 3.36-Linux master/d96f8968a Feb 02 2026 GCC 12.2.0   
   BBSID: VERT   
   CHRS: ASCII 1   
   FORMAT: flowed   
   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.   
   --- SBBSecho 3.36-Linux   
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)   
   SEEN-BY: 103/705 105/81 106/201 124/5016 128/187 129/14 153/757 7715   
   SEEN-BY: 154/10 30 110 203/0 218/700 221/0 226/30 227/114 229/110   
   SEEN-BY: 229/134 206 317 400 426 428 470 700 705 240/1120 5832 263/1   
   SEEN-BY: 266/512 280/464 5003 5006 291/111 292/8125 301/1 320/219   
   SEEN-BY: 322/757 341/66 234 342/200 396/45 423/120 460/58 256 1124   
   SEEN-BY: 633/280 712/848 770/1 902/26 5020/400 8912 5054/30 5075/35   
   PATH: 103/705 280/464 460/58 229/426