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