1. Forum
  2. DOVE-Net
  3. Synchronet Sysops

  • Investigate potential user.dat file leak

    From Rob Swindell@VERT to GitLab issue in main/sbbs on Mon Mar 8 04: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.

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Michael J. Ryan@VERT to GitLab note in main/sbbs on Wed Mar 10 17: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.

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Deuc¿@VERT to GitLab note in main/sbbs on Fri Mar 12 19: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.

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Deuc¿@VERT to GitLab note in main/sbbs on Fri Mar 12 22: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.

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Nigel Reed@VERT to GitLab note in main/sbbs on Sat Apr 10 09:19:12 2021
    https://gitlab.synchro.net/main/sbbs/-/issues/235#note_1930

    root@bbs:~# lsof|grep user.dat|wc -l
    1326

    ok, 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/webS

    There's 1 user connection and all my other nodes are waiting for connection. There's only 8 established http or https sessions.

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Deuc¿@VERT to GitLab note in main/sbbs on Tue Apr 13 16: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.

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell@VERT to GitLab issue in main/sbbs on Fri Apr 15 23:23:33 2022
    close https://gitlab.synchro.net/main/sbbs/-/issues/235

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell@VERT to GitLab note in main/sbbs on Fri Apr 15 23:23:34 2022
    https://gitlab.synchro.net/main/sbbs/-/issues/235#note_2557

    Investigation considered complete: no leak

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