home bbs files messages ]

Just a sample of the Echomail archive

Cooperative anarchy at its finest, still active today. Darkrealms is the Zone 1 Hub.

   BINKD      Support for the Internet BinKD mailer      8,958 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 7,831 of 8,958   
   mark lewis to Michiel van der Vlist   
   binkd crashes when reloading after file    
   20 Jan 22 09:12:42   
   
   REPLY: 1:3634/12.73 61e96dc7   
   MSGID: 1:3634/12.73 61e982b7   
   PID: GED+LNX 1.1.5-b20180707   
   CHRS: CP437 2   
   TZUTC: -0500   
   TID: hpt/lnx 1.9.0-cur 17-02-17   
    On 2022 Jan 20 08:55:17, I wrote to you:   
      
    MV>> I gave up and stopped using the -C option.   
      
    ml> i've continued to use it but have always stopped my binkd manually before   
    ml> making and saving edits... [...]   
      
   earlier i had remove the "-C" to test the automatic reload that the FAQ seems   
   to indicate is done with binkd v1.xx... i've just put it back and run a short   
   but similar test to your's using touch on my main configuration file as well   
   as each of the various included files... in every case, binkd did detect the   
   timestamp updates and said it reloaded the configure for both server and   
   client instances... there was no crash...   
      
   ok, so that works... let's try changing some content...   
      
   first test is manually changing the case of a comment in my main binkd.conf   
   file... both instances reloaded just fine... tested this several times   
   changing only the case of some comment text... no problems... hummm...   
      
   second test is manually changing the case of a comment in the first include   
   file, my binkd-networks.conf... again, both instances reloaded just fine...   
   tested this several times, too... no problems... hummm...   
      
   third test is manually changing the case of a comment in another include   
   file... same as the two previous tests... no crash... ok... hummm...   
      
   4th test... now we'll add a blank line to the end of the main config file...   
   no crash... ok, remove that blank line... no crash... alright...   
      
   5th test... just like 4th, we'll add a blank line to the end of the first   
   included file... no crash... ok... remove that blank line... and again, no   
   crash...   
      
   this is getting curiousier and curiouser...   
      
   6th test... we'll change the data somewhere... we'll change "timeout 1m" to   
   "timeout 45s" in the main conf file... that'll add one byte to the file,   
   itself...no crash... ok, change it back... again, no crash...   
      
   7th test... now we'll change a data line in the first include file... that's   
   the file that triggered my initial post in this thread... we'll comment out a   
   domain line for a network known to no longer exist... all we're doing is   
   adding a '#' to the beginning of that domain line... that'll add one byte and   
   remove some data when binkd processes the contents... damn! again no crash...   
   remove the content so that domain line is valid again and no crash... WTAF is   
   going on??   
      
   8th test... instead of commenting out that domain line, i've completely   
   removed it... no crash... put it back by copying a backup copy of the file   
   back over the one we've edited... again no crash...   
      
   i don't get it...   
      
   [time passes]   
      
   ahhh... if i'm reading the output of "ps aux" properly, there is a bit of a   
   memory leak going on... perhaps the crashes i was able to trigger are the   
   result of a combination of some memory leakage over a "long" running time   
   coupled with changing a config or included file? i'll try to set something up   
   to test this possibility further but i'm done manually beating on it by   
   editing files for now ;)   
      
   clean start   
   USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND   
   sbbs     17629  0.6  0.2  13980  2932 pts/1    S+   09:48   0:00 binkd: server   
   manager (listen 24554)   
   sbbs     17630  0.0  0.2  14028  2244 pts/1    S+   09:48   0:00 binkd: client   
   manager   
      
   remove domain line as in 8th test   
   USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND   
   sbbs     17629  0.1  0.3  14648  3684 pts/1    S+   09:48   0:00 binkd: server   
   manager (listen 24554)   
   sbbs     17630  0.1  0.2  14708  2988 pts/1    S+   09:48   0:00 binkd: client   
   manager   
      
   copy back file over edited file restoring domain line as in 8th test   
   USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND   
   sbbs     17629  0.1  0.3  14784  3844 pts/1    S+   09:48   0:00 binkd: server   
   manager (listen 24554)   
   sbbs     17630  0.2  0.3  14868  3204 pts/1    S+   09:48   0:00 binkd: client   
   manager   
      
      
   the above may also not be quite scientific as there was at least one mail   
   connection at one stage... i don't recall if there was any actual files moved,   
   though... so i've whipped up a quick script that will monitor and log binkd's   
   memory usage... it'll take a reading as above once every 5 minutes... let's   
   see what we find...   
      
   where's my asprin?   
      
   )\/(ark   
      
   "The soul of a small kitten in the body of a mighty dragon. Look on my   
   majesty, ye mighty, and despair! Or bring me catnip. Your choice. Oooh, a   
   shiny thing!"   
   ... There is no such thing as arugula yet many gourmet recipes call for it.   
   ---   
    * Origin:  (1:3634/12.73)   
   SEEN-BY: 1/120 123 15/0 18/0 90/1 105/81 106/201 114/709 116/116 120/340   
   SEEN-BY: 123/0 25 40 115 126 131 180 190 200 755 129/305 330 135/300   
   SEEN-BY: 138/146 153/7715 154/10 222/2 226/30 227/114 229/110 200   
   SEEN-BY: 229/307 317 424 426 550 664 700 240/1120 5832 249/206 250/1   
   SEEN-BY: 266/512 275/100 1000 282/1038 292/854 299/6 300/4 301/1 317/3   
   SEEN-BY: 320/219 322/757 342/11 200 396/45 633/280 640/1321 1384 712/848   
   SEEN-BY: 3634/0 12 15 27 50 119   
   PATH: 3634/12 153/7715 229/426   
      

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca