Subj : binkd crashes when reloading after file change detection To : Oli From : mark lewis Date : Thu Jan 20 2022 07:10 am 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) .