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