• Investigate potential user.dat file leak

    From Rob Swindell@1:103/705 to GitLab issue in main/sbbs on Sun Mar 7 20:31:23 2021
    open https://gitlab.synchro.net/main/sbbs/-/issues/235

    The user.dat file is excessively opened (> 100 times) on cvs.synchro.net under common operation (mostly web traffic). The number does go down < 100 sometimes, so likely not an actual leak, but still - something to investigate.
    --- SBBSecho 3.13-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Michael J. Ryan@1:103/705 to GitLab note in main/sbbs on Wed Mar 10 09:54:45 2021
    https://gitlab.synchro.net/main/sbbs/-/issues/235#note_1693

    Guest user? (Or any logged in user for that matter) per request... usually several per page request for active browsers.Not sure if Synchronet's Web server is setting caching rules or responding with 304 for if-modified-since or etag headers. Though any desired effect may vary.
    --- SBBSecho 3.13-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Deucе@1:103/705 to GitLab note in main/sbbs on Fri Mar 12 11:56:44 2021
    https://gitlab.synchro.net/main/sbbs/-/issues/235#note_1699

    My guess would be it's in JS User objects since they aren't finalized until they're collected which would likely be at the end of the HTTP session.
    --- SBBSecho 3.13-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Deucе@1:103/705 to GitLab note in main/sbbs on Fri Mar 12 14:10:48 2021
    https://gitlab.synchro.net/main/sbbs/-/issues/235#note_1700

    Actually, it looks like the HTTP server runs a full GC after each request, so it may be more likely to be in the terminal server unless you tend to have over 100 active requests at any given time.
    --- SBBSecho 3.13-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Nigel Reed@1:103/705 to GitLab note in main/sbbs on Sat Apr 10 02:19:12 2021
    https://gitlab.synchro.net/main/sbbs/-/issues/235#note_1930

    root@bbs:~# lsof|grep user.dat|wc -l1326ok, that does appear somewhat excessive.root@bbs:~# lsof|grep user.dat|cut -c25-40|sort|uniq -c 26 52 sbbs/even 26 sbbs/ftpS 442 sbbs/http 130 sbbs/jsBa 26 sbbs/jsRT 52 sbbs/jsSe 182 sbbs/jsSt 26 sbbs/mail 26 sbbs/pass 26 sbbs/send 26 sbbs/serv 26 sbbs/sigH 26 sbbs/smtp 26 sbbs/stat 156 sbbs/term 26 sbbs/webSThere's 1 user connection and all my other nodes are waiting for connection. There's only 8 established http or https sessions.
    --- SBBSecho 3.14-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Deucе@1:103/705 to GitLab note in main/sbbs on Tue Apr 13 09:27:32 2021
    https://gitlab.synchro.net/main/sbbs/-/issues/235#note_1942

    I'm not sure what you're trying to show here... lsof without -Ki lists every descriptor for every thread (ie: the number of lines equals the total number of descriptors times the total number of threads). It looks like sbbs has at most 26 file descriptors for user.dat open, and you have 17 FTP clients connected and are running 7 (!) static services.26 doesn't seem excessive when you have 17 FTP sessions.
    --- SBBSecho 3.14-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)