1. Forum
  2. DOVE-Net
  3. Synchronet Programming C+

  • src/sbbs3/ftpsrvr.c mailsrvr.c main.cpp services.c websrvr.c

    From rswindell@VERT to CVS commit on Tue Jan 7 18:41:22 2014
    src/sbbs3 ftpsrvr.c 1.402 1.403 mailsrvr.c 1.565 1.566 main.cpp 1.599 1.600 services.c 1.272 1.273 websrvr.c 1.570 1.571
    Update of /cvsroot/sbbs/src/sbbs3
    In directory cvs:/tmp/cvs-serv16729

    Modified Files:
    ftpsrvr.c mailsrvr.c main.cpp services.c websrvr.c
    Log Message:
    More _beginthread() race condition fixes to prevent recycle and terminate related crashes (mainly due to null pointer dereferences of scfg_t members freed in cleanup()).
    Use of new protected_int_value() for extra paranoia (but can't use it on destroyed protected-int's).

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ telnet://vert.synchro.net
  • From rswindell@VERT to CVS commit on Sat Nov 19 02:21:16 2016
    src/sbbs3 ftpsrvr.c 1.426 1.427 mailsrvr.c 1.598 1.599 main.cpp 1.639 1.640 services.c 1.294 1.295 websrvr.c 1.638 1.639
    Update of /cvsroot/sbbs/src/sbbs3
    In directory cvs:/tmp/cvs-serv11055

    Modified Files:
    ftpsrvr.c mailsrvr.c main.cpp services.c websrvr.c
    Log Message:
    Fix the root-cause of the high-CPU utlization on server recycle problem:
    How did startup->sem_chk_freq get set (back) to 0 in the first place?
    The reason: the startup struct sanitization only occured when the various server threads were first started. When recycled, the server would call back to the original caller (e.g. sbbscon) which may (and did) re-read the sbbs.ini file, which could have SemCheckFrequency set to 0 (or missing) and the sanitization did not happen again (so a 0 value was used in select() calls, resuilting in high CPU utilization for several threads).

    So now, all startup struct sanitization occurs inside the init/recycle loop
    and sem_chk_freq should never revert to 0 again. This was the main bug.

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ telnet://vert.synchro.net
  • From rswindell@VERT to CVS commit on Sun Nov 20 21:44:00 2016
    src/sbbs3 ftpsrvr.c 1.428 1.429 mailsrvr.c 1.600 1.601 main.cpp 1.642 1.643 services.c 1.296 1.297 websrvr.c 1.640 1.641
    Update of /cvsroot/sbbs/src/sbbs3
    In directory cvs:/tmp/cvs-serv8390

    Modified Files:
    ftpsrvr.c mailsrvr.c main.cpp services.c websrvr.c
    Log Message:
    Log the correct number of "unique" failed login attempts which triggers a temp-ban (was logging the total number of login attempts, including dupes).

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ telnet://vert.synchro.net
  • From rswindell@VERT to CVS commit on Thu Mar 22 18:19:20 2018
    src/sbbs3 ftpsrvr.c 1.463 1.464 mailsrvr.c 1.659 1.660 main.cpp 1.699 1.700 services.c 1.318 1.319 websrvr.c 1.663 1.664
    Update of /cvsroot/sbbs/src/sbbs3
    In directory cvs:/tmp/cvs-serv7874

    Modified Files:
    ftpsrvr.c mailsrvr.c main.cpp services.c websrvr.c
    Log Message:
    Clean-up the log output around server shutdown/recycle:
    - lower log level (raise severity) of "Waiting for ..." msgs from Debug to Info - log a message when done waiting (for clients, threads, etc.)
    - only one #### log line per termination event

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From rswindell@VERT to CVS commit on Thu Jun 20 13:48:53 2019
    src/sbbs3 ftpsrvr.c 1.492 1.493 mailsrvr.c 1.697 1.698 main.cpp 1.750 1.751 services.c 1.329 1.330 websrvr.c 1.683 1.684
    Update of /cvsroot/sbbs/src/sbbs3
    In directory cvs:/tmp/cvs-serv19319

    Modified Files:
    ftpsrvr.c mailsrvr.c main.cpp services.c websrvr.c
    Log Message:
    Implement mark lewis' enhancement to always log the client IP address after the resolved host-name on "Hostname:" log lines.

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on Windows 11)@VERT to Git commit to main/sbbs/master on Sat Dec 16 23:18:56 2023
    https://gitlab.synchro.net/main/sbbs/-/commit/f7ba1e65339411c65a6b2d16
    Modified Files:
    src/sbbs3/ftpsrvr.c mailsrvr.c main.cpp services.c websrvr.c
    Log Message:
    Commonize more of the log messages format/severity among the servers

    ... especially around incoming connection acceptance, blocked-IPs/hostnames
    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on Windows 11)@VERT to Git commit to main/sbbs/master on Wed Feb 14 15:11:56 2024
    https://gitlab.synchro.net/main/sbbs/-/commit/14ad4003fb0663e3330f690e
    Modified Files:
    src/sbbs3/ftpsrvr.c mailsrvr.c main.cpp services.c websrvr.c
    Log Message:
    Recycling servers reverts back to graceful (waiting for clients to disconnect)

    Commit 63d0772d was initially to address server termination (sisue #236), but expanded in scope to include server recycling (e.g. due to semaphore/config file touch) and that turns out to not be what most sysops want.

    If you want an immediate/ungraceful recycle, do a restart (shutdown/stop and then start) instead.

    Immediate/ungraceful server shutdown/termination is still in effect however.

    No change to the "server pause" feature either, so combining pause with
    recycle would be effective to prevent *new* client connections while waiting for existing clients to disconnect and allow a recycle to happen.
    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on Debian Linux)@VERT to Git commit to main/sbbs/master on Mon Jun 16 19:06:06 2025
    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