binkd11a77-mingw32-ipv6-perldl.zip
binkd11a77-mingw32-ipv6-perldl.zip
In principle that is the same error I had with 1.1a75 o Linux.
The error is not there when binkd is compiled without perl-hooks,
The cause must be in the latest changes in perlhooks somewhere
between 1.1a73 and 1.1a75.
In principle that is the same error I had with 1.1a75 o Linux. The
error is not there when binkd is compiled without perl-hooks, The
cause must be in the latest changes in perlhooks somewhere between
1.1a73 and 1.1a75.
Michiel van der Vlist wrote to Max Vasilyev <=-
On Wednesday January 20 2016 13:50, you wrote to All:
binkd11a77-mingw32-ipv6-perldl.zip
It appears to be unstable on my system. (WinXP)
12:20 [964] trying eljaco.se [90.231.158.147]:24554...
12:20 [964] connected
+ 12:20 [964] outgoing session with eljaco.se:24554 [90.231.158.147]
- 12:20 [964] OPT CRAM-MD5-c2865fe82bd7eec2655301029eacaeee
+ 12:20 [964] Remote requests MD mode
- 12:20 [964] SYS Felten's Testbench
- 12:20 [964] ZYZ Bj.rn Felten
- 12:20 [964] LOC S.ve, Sweden
- 12:20 [964] NDL 115200,TCP,BINKP
- 12:20 [964] TIME Wed, 20 Jan 2016 12:19:53 +0100
- 12:20 [964] VER binkd/1.1a-65/Win32 binkp/1.1
+ 12:20 [964] addr: 2:203/0@fidonet
+ 12:20 [964] addr: 2:20/0@fidonet
+ 12:20 [964] addr: 2:2/2@fidonet
- 12:20 [964] TRF 0 0
+ 12:20 [964] Remote has 0b of mail and 0b of files for us
- 12:20 [964] OPT EXTCMD CRYPT
+ 12:20 [964] Remote supports EXTCMD mode
+ 12:20 [964] Remote requests CRYPT mode
+ 12:20 [964] pwd protected session (MD5)
- 12:20 [964] session in CRYPT mode
+ 12:20 [964] done (to 2:203/0@fidonet, OK, S/R: 0/0 (0/0 bytes))
binkd - transfer files between two Fidonet systems over hat ein Problem festgestellt und muss beendet werden.
So it exits with an error and the .try and .bsy flags are set.
D:\FIDO\OUTBOUND>dir 00cb0000.*
Datentr.ger in Laufwerk D: ist T?ger
Volumeseriennummer: F84B-BCCB
Verzeichnis von D:\FIDO\OUTBOUND
20/01/2016 12:20 6 00cb0000.csy
20/01/2016 12:20 16 00cb0000.try
2 Datei(en) 22 Bytes
0 Verzeichnis(se), 31.152.603.136 Bytes frei
D:\FIDO\OUTBOUND>
So... I am going back to 1-1A73 :-(
And I don't know what the 'binkd9x' stands for,
And I don't know what the 'binkd9x' stands for,
win9x -- w95, w98, w98se...
The x64 probably not. And I don't know what the 'binkd9x' stands for,
and it lacks IPv6. But you could just test it.
Btw: I hope 11a81 for windows is published tomorrow... ;)
On linux without perlhooks it's working for me.
The x64 probably not. And I don't know what the 'binkd9x' stands
for, and it lacks IPv6. But you could just test it.
Btw: I hope 11a81 for windows is published tomorrow... ;)
On linux without perlhooks it's working for me.
-81 Compiles fine with cygwin, both 32bit and 64bit. No perl.
Now running at 2:221/6:
Binkd 1.1a-81 (Jan 20 2016 18:06:20/CYGWIN_NT-5.2)
Compilation flags: gcc, zlib, bzlib2, https, bwlim.
Facilities: fts5004 ipv6
-81 Compiles fine with cygwin, both 32bit and 64bit. No perl.
Now running at 2:221/6:
Binkd 1.1a-81 (Jan 20 2016 18:06:20/CYGWIN_NT-5.2)
Compilation flags: gcc, zlib, bzlib2, https, bwlim.
Facilities: fts5004 ipv6
Have to agree with you on this one. Started a session and locked up
in the middle and seems like all nodes in my password list had BSY/CSY flags set immediately.
And I don't know what the 'binkd9x' stands for,
win9x -- w95, w98, w98se...
What's that? 16 bits? Probably not. So if it's 32 bit it should work
on Win32, like XP too...
-81 Compiles fine with cygwin, both 32bit and 64bit. No perl.
Now running at 2:221/6:
Binkd 1.1a-81 (Jan 20 2016 18:06:20/CYGWIN_NT-5.2)
Compilation flags: gcc, zlib, bzlib2, https, bwlim.
Facilities: fts5004 ipv6
That's great! Can you publish those, so Michiel can test it on his
system?
win9x -- w95, w98, w98se...
What's that? 16 bits? Probably not. So if it's 32 bit it should work
on Win32, like XP too...
i honestly don't remember right now but it is the old windows95/98 shite which is, TTBOMK, dropped for binkd... it is well out of servicable life ;)
http://cow.mine.nu/binkd-cyg/
But as I told Michiel in netmail, I don't know how many cygwin dll's
may be needed. :(
Maybe you can test one of the versions without perlhooks?
binkd11a77-msvc-binkd9x-static.zip binkd11a77-msvc10x64-4gb-ipv6-static-zlib-bzlib2.zip
The x64 probably not. And I don't know what the 'binkd9x' stands for,
and it lacks IPv6. But you could just test it.
Btw: I hope 11a81 for windows is published tomorrow... ;)
On linux without perlhooks it's working for me.
Michiel van der Vlist
This is binkd, yes? Not Tedious? 8-)
Can it have been my system that caused it?
Btw: I hope 11a81 for windows is published tomorrow... ;)
On linux without perlhooks it's working for me.
There are no changes regarding perlhooks. 76 upto 81 are related to my commits regarding ip address 0.0.0.0 and [::] detection. That was a
bit noisy because I'm not too familiar with the pull request process.
I've entered an "issue" on https://github.com/pgul/binkd/issues ,
because I'm not to sure Pavel is following this area very closely.
I've entered an "issue" on https://github.com/pgul/binkd/issues ,
because I'm not to sure Pavel is following this area very closely.
But as I told Michiel in netmail, I don't know how many cygwin dll's
may be needed. :(
Ik complains about not finding cygbz2-1.dll....
OK. But I was also thinking that maybe it was an "internal" binkd
to binkd problem. Have you seen it happening with contacts with e.g. Radius (Paul Q) or Tedious (my Argus clone)?
problem. Have you seen it happening with contacts with e.g. Radius (Paul Q) or Tedious (my Argus clone)?
binkd11a77-mingw32-ipv6-perldl.zip
binkd11a77-mingw32-ipv6-perldl.zip
The problem is fixed in 1.1a-87. Current snapshop is 1.1a-89.
Thanks for testing!
Thanks for testing!
Yes, some code related to reloading config was changed, but I'm not
sure was the problem in fact fixed or the bug is just hidden and will occure rarely.
Do you use perl hooks?
Do you run binkd with -s or -c option?
No, I do not use the perl hooks. If Max were to compile anotherHave a try with -89.
version without the perl hooks, but with zlib, I will happily test it.
Yes, some code related to reloading config was changed, but I'm not
sure was the problem in fact fixed or the bug is just hidden and will
occure rarely.
Now I built linux multithread binkd version, started it on my node and with -C switch and touch config every 5 minutes. 2 days running - no errors. :-(
Could you please show binkd logs (as detailed as you have) before the crash?
And do you have "exec" parameters in binkd config? If yes, it's
possible that listen socket inherited by executed external utility,
then binkd reopen the socket on config reload, and cannot bind listen socket because it's "already in use". Problem with socket inheritance described here: http://stackoverflow.com/questions/12058911/can-tcp-socket-handles-be- set-not-inheritable AFAIU it's possible to workaround by
DuplicateHandle() and set "noinherit" attribute, but it's not easy to
test it in binkd.
Yes, I have to exec statements in my config:
exec "!d:\\fido\\allfix\\allfix.exe RP -SRIF *S" *.REQ
exec d:\\fido\\batch\\mailrcvd.bat *
Over here I have 4 exec lines. Two of them just run scripts to do some external stuff, but every one of them quote the path to what is
supposed to be executed. I'm not sure if this makes any difference,
but it's worth a shot I suppose.
Now I built linux multithread binkd version, started it on my node and with -C switch and touch config every 5 minutes. 2 days running - no errors. :-(
I am presently doing the same with binkd11a89-mingw32-ipv6-zlib
It has been running for a few hours now. No crash yet. Stay tuned....
Michiel van der Vlist wrote to Pavel Gulchouck <=-
Hello Pavel,
Saturday January 30 2016 16:38, I wrote to you:
I am presently doing the same with binkd11a89-mingw32-ipv6-zlib
It has been running for a few hours now. No crash yet. Stay tuned....
Been running for more than 24 hours now. Config has been reloaded some 300 times. No error yet. Looks good!
Been running for more than 24 hours now. Config has been
reloaded some 300 times. No error yet. Looks good!
300 times? LOL... what the hell are you doing over there?? ;)
Michiel van der Vlist wrote to Bill McGarrity <=-
On Sunday January 31 2016 12:38, you wrote to me:
Been running for more than 24 hours now. Config has been
reloaded some 300 times. No error yet. Looks good!
300 times? LOL... what the hell are you doing over there?? ;)
Previous W32 versions of binkd (<= 1.88) occasionally crashed when run with the -C option when the config file or one of the include files declared in the config files changed and it reloaded it config. 1.89 appears to be stable, but to test its stability I created an event that touches an empty file every five minutes. This empy file is declared as an include in my binkd.cfg. This forces binkd to reload its config
every five minutes.
So far, so good...
Ahhh.... even with earlier versions I never had an issue with binkd updating itwelf when a cfg/txt file was changed. Still don't have it
with 1.89 either... guess I was lucky.
It has been running for a few hours now. No crash yet. Stay
tuned....
Been running for more than 24 hours now. Config has been reloaded some
300 times. No error yet. Looks good!
Been running for 100+ hours. Config has been reloaded more than 1200 times. So far so good... :-)
Been running for 100+ hours. Config has been reloaded more than 1200
times. So far so good... :-)
Has the size of your config files changed in this period? Or only the date/time stamp of the file?
Has the size of your config files changed in this period? Or only the
date/time stamp of the file?
I know. ;)
But if only the date/time of the config file changes it's a very
limited test, and not very realistic.
If for instance the same reserved memory is used to load the new file
it doesn't matter if the new file has the same size or is smaller. But
if it's bigger you could get a memory violation...
| Sysop: | digital man |
|---|---|
| Location: | Riverside County, California |
| Users: | 1,027 |
| Nodes: | 17 (0 / 17) |
| Uptime: | 62:16:54 |
| Calls: | 502,334 |
| Calls today: | 2 |
| Files: | 100,779 |
| D/L today: |
10,704 files (1,012M bytes) |
| Messages: | 300,075 |