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,826 of 8,958   
   mark lewis to Oli   
   binkd crashes when reloading after file    
   20 Jan 22 07:10:54   
   
   REPLY: 2:280/464.47 61e938fe   
   MSGID: 1:3634/12.73 61e95151   
   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 11:27:14, you wrote to me:   
      
    AK>>> It helped me to add the following line to the binkd config   
      
    AK>>> rescan-delay 10   
      
    ml>> sysname "SouthEast Star (binkd)"   
    ml>> location "central North Carolina, USA"   
    ml>> sysop "waldo kitty"   
    Ol> [...]   
    ml>> timeout 1m   
    ml>> connect-timeout 10s   
    ml>> call-delay 1s   
    ml>> rescan-delay 10s   
      
    Ol> You are saying the proposed rescan-delay workaround isn't working for you?   
      
   yes... it has been in my configs for decades through quite a few different   
   binkd versions and flavors... i had it in place on my old OS/2 system and   
   simply copied that config over to this new linux setup with a few minor   
   modifications (mainly for directory paths)...   
      
   the automatic configs reloading feature (-C command line option) used to work   
   just fine... i don't know what code changed or when that caused it to break   
   but it has been a defect for a long while now... when mvdv first reported it,   
   i was able to replicate it instantly which also lead me to realizing that my   
   automated update process was flawed at the time because each new nodelist   
   arrival should have been triggering it at least once a week... then the daily   
   nodelists came out and i switched to them which means the defect is or could   
   be triggered every day now depending on some factors i've not fully sussed   
   yet...   
      
   i can trigger the defect by editing one of my configs with mcedit and saving   
   the changes but it does not seem to be triggered when my script updates the   
   fidonet.binkd.txt file every night about local midnight when the Z1C's system   
   delivers it... all three dates and possibly the file's size change when it is   
   updated but binkd doesn't seem to notice it... at least, i don't find any   
   entries in the log when the nodelist is updated like i saw when i edited my   
   binkd-networks.conf file yesterday to see if the defect still existed...   
      
   [edit1]   
   hummm... i see that the binkd.faq has changed a little bit for the "-C"   
   command line option... note the last paragraph below...   
      
   =====>8 snip 8<=====   
           11. I Have Changed binkd Configuration File On-The-Fly. When Will It   
   Be Reloaded?   
      
       Starting with the version 0.9.1 binkd could feel that its configuration   
   file changed. It exited with code 3 if it had been started with option -C.   
   Modification time was checked after each ingoing session. Here is the batch   
   file for starting binkd versions 0.9.1-0.9.3 and 0.9.4-0.9.6/w32:   
      
       ====   
       :aaa   
       binkd -C binkd.cfg   
       if errorlevel 4 goto end   
       if errorlevel 3 goto aaa   
       :end   
       ====   
      
       In the versions 0.9.4/unix and /os2-emx (and in these ones only) binkd   
   restarts automatically if it is started with -C command line option.   
   Besides that starting with version 0.9.4 the files included into the   
   configuration file with the help of 'include' keyword are tested not only   
   on incoming sessions but also in every 'rescan-delay' seconds.   
      
       If you install binkd 0.9.4/w32 as a Windows NT service you should use it   
   with -C command line option.  Then binkd re-reads its configuration file.   
      
       Before version 0.9.4 changes in the configuration file were not tested if   
   binkd was started in client-only mode (-c command line option).   
      
       In the unix versions configuration file is re-read on SIGHUP signal   
   by the command   
       kill -HUP `cat /var/run/binkd.pid`   
      
       In the version 1.0 configuration file is re-read automatically if   
   changed. binkd tests on changes at every 'rescan-delay' seconds.   
   =====>8 snip 8<=====   
      
   so that last paragraph now makes me wonder if my continued use of the "-C"   
   command line option is why i'm seeing this double free defect being   
   triggered... in other words, is binkd noticing it automatically and then the   
   "-C" is causing it to do the reload again? idk :thinking: it seems to only   
   happen when the client side reloads when running as both server and client at   
   the same time... the server part reloading seems fine... are they sharing the   
   same in-memory config states and the client one is not noticing that the   
   server side has already reloaded the state and dropped the old pointer?   
   [/edit1]   
      
    Ol> Someone has to fix the bug or the only reliable workaround is to   
    Ol> disable rescan.   
      
   that option seems to be only(?)/mainly(?) for rescanning the outbound   
   directories... at least from what binkd.conf-dist says...   
      
   =====>8 snip 8<=====   
   # Delay of calls and outbound rescans in seconds   
   #   
   #call-delay 1m   
   #rescan-delay 1m   
   =====>8 snip 8<=====   
      
   [edit2]   
   but in light of what the FAQ now states (above), this has me wondering about   
   using "-C" any more... at least on my 64bit native linux builds... hummm   
   :thinking:   
   [/edit2]   
      
   [edit3]   
   as a test i stopped my binkd, edited my startup script to remove the "-C"   
   option, and restarted it... then i edited my binkd-networks.conf file which is   
   included as previously shown... 5 minutes later and binkd still has not   
   noticed the change contrary to what the FAQ's last paragraph above states   
   about the configs being re-read automatically...   
      
   i /HAD/ to use the -HUP method to trigger binkd to notice the changes... i   
   tested this a few times and the -HUP method is the only way it works without   
   the "-C" command line option... ugh... that's really not how automated updates   
   should be handled :(  but at least binkd doesn't crash so i guess there is a   
   bit of a wry smile needed, too :?   
   [/edit3]   
      
    Ol> Does someone know, if this bug also affects binkd running in   
    Ol> client-only mode?   
      
   idk...   
      
   )\/(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!"   
   ... You're scary. Why are you so "Out There"? Take a deep breath.   
   ---   
    * 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