1. Forum
  2. FidoNet
  3. SYNC SYSOPS

  • Investigate potential user.dat file leak

    From Rob Swindell@1:103/705 to GitLab issue in main/sbbs on Sunday, March 07, 2021 20:31:23
    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 Wednesday, March 10, 2021 09:54:45
    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 Friday, March 12, 2021 11:56:44
    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 Friday, March 12, 2021 14:10:48
    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 Saturday, April 10, 2021 02:19:12
    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 Tuesday, April 13, 2021 09:27:32
    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)
  • From Rob Swindell@1:103/705 to GitLab issue in main/sbbs on Friday, April 15, 2022 23:23:33
    close https://gitlab.synchro.net/main/sbbs/-/issues/235
    --- SBBSecho 3.15-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Rob Swindell@1:103/705 to GitLab note in main/sbbs on Friday, April 15, 2022 23:23:34
    https://gitlab.synchro.net/main/sbbs/-/issues/235#note_2557

    Investigation considered complete: no leak
    --- SBBSecho 3.15-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)