Fidonet Portal
On 18 Jan 21 12:06:52, Rob Swindell said the following to Nick Andre:
RS> https://www.computerhope.com/taskkill.htm
Already tried that. Kills BinkD and all active connections.
Nick
--- Renegade vY2Ka2
* Origin: Joey, do you like movies about gladiators? (1:229/426)
RS> https://www.computerhope.com/taskkill.htm
Already tried that. Kills BinkD and all active connections.
Nick
--- Renegade vY2Ka2
* Origin: Joey, do you like movies about gladiators? (1:229/426)
Re: Re: Semaphore
By: Nick Andre to Rob Swindell on Mon Jan 18 2021 03:25 pm
> On 18 Jan 21 12:06:52, Rob Swindell said the following to Nick Andre:
>
> RS> https://www.computerhope.com/taskkill.htm
>
> Already tried that. Kills BinkD and all active connections.
Does BinkD log the "got signal" message?
Here's the relevant code:
https://github.com/pgul/binkd/blob/master/breaksig.c
--
digital man
Synchronet/BBS Terminology Definition #2:
ARS = Access Requirement Strings
--- SBBSecho 3.12-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
By: Nick Andre to Rob Swindell on Mon Jan 18 2021 03:25 pm
> On 18 Jan 21 12:06:52, Rob Swindell said the following to Nick Andre:
>
> RS> https://www.computerhope.com/taskkill.htm
>
> Already tried that. Kills BinkD and all active connections.
Does BinkD log the "got signal" message?
Here's the relevant code:
https://github.com/pgul/binkd/blob/master/breaksig.c
--
digital man
Synchronet/BBS Terminology Definition #2:
ARS = Access Requirement Strings
--- SBBSecho 3.12-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
On 18 Jan 2021 at 08:34a, Dallas Hinton pondered and said...
DH> Hi, Dan -- on Jan 19 2021 at 03:11, you wrote:
DH>
DH> DC> A couple of things, but the biggest one I can think of is fragility
DH> DC> in the face of system crashes. In particular, who's responsible for
DH> DC> cleaning this file up? Should `binkd` delete it as part of gracefully
DH>
DH> FWIW, I have a batch file that runs on startup and deletes all semaphore
DH> flags. They're all in the same directory so it's easy.
Yeah, that's _a_ design, but doesn't really address the
question. The program author still has to make some kind
of design decision about what to do if the file exists
when the program starts up (suppose someone starts it
directly, without running the script that deletes the files
ahead of time?
.
More generally, the issue in this discussion is that the
request for a feature has been wrapped up in details about
the implementation of that feature. From my observation,
that's the central source of friction.
--- Mystic BBS v1.12 A46 2020/08/26 (Windows/32)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (3:770/100)
DH> Hi, Dan -- on Jan 19 2021 at 03:11, you wrote:
DH>
DH> DC> A couple of things, but the biggest one I can think of is fragility
DH> DC> in the face of system crashes. In particular, who's responsible for
DH> DC> cleaning this file up? Should `binkd` delete it as part of gracefully
DH>
DH> FWIW, I have a batch file that runs on startup and deletes all semaphore
DH> flags. They're all in the same directory so it's easy.
Yeah, that's _a_ design, but doesn't really address the
question. The program author still has to make some kind
of design decision about what to do if the file exists
when the program starts up (suppose someone starts it
directly, without running the script that deletes the files
ahead of time?
.
More generally, the issue in this discussion is that the
request for a feature has been wrapped up in details about
the implementation of that feature. From my observation,
that's the central source of friction.
--- Mystic BBS v1.12 A46 2020/08/26 (Windows/32)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (3:770/100)
On 18 Jan 21 12:31:02, Rob Swindell said the following to Nick Andre:
RS> Looking at the source code, it appears that BinkD already behaves exactly a
RS> you are requesting it to behave: When it receives SIGBREAK, SIGINT, or
RS> SIGTERM, it sets the 'binkd_exit' global flag and then terminates when idle
RS> that flag is set.
Nope, it does not appear to function this way on Windows. Set up a test
transaction of a large file just over 300 meg. Close with Taskkill. Active
session closes and notes a failure in the log... not terminating on "idle".
20210118 15:53:15 [5884] Remote has 0b of mail and 335278080b of files for us
20210118 15:53:15 [5884] pwd protected session (MD5)
20210118 15:53:15 [5884] session in CRYPT mode
20210118 15:53:15 [5884] receiving X1-240~1.SNA (335278080 byte(s), off 0)
20210118 15:53:19 [5552] Interrupted by Close
20210118 15:53:19 [4692] downing servmgr...
20210118 15:53:19 [5884] done (from 1:229/427@fidonet, failed, S/R: 0/0 (0/0
bytes)
20210118 15:53:19 [5884] receiving of X1-240~1.SNA interrupted at 13475840
20210118 15:53:19 [5884] session closed, quitting...
Nick
--- Renegade vY2Ka2
* Origin: Joey, do you like movies about gladiators? (1:229/426)
RS> Looking at the source code, it appears that BinkD already behaves exactly a
RS> you are requesting it to behave: When it receives SIGBREAK, SIGINT, or
RS> SIGTERM, it sets the 'binkd_exit' global flag and then terminates when idle
RS> that flag is set.
Nope, it does not appear to function this way on Windows. Set up a test
transaction of a large file just over 300 meg. Close with Taskkill. Active
session closes and notes a failure in the log... not terminating on "idle".
20210118 15:53:15 [5884] Remote has 0b of mail and 335278080b of files for us
20210118 15:53:15 [5884] pwd protected session (MD5)
20210118 15:53:15 [5884] session in CRYPT mode
20210118 15:53:15 [5884] receiving X1-240~1.SNA (335278080 byte(s), off 0)
20210118 15:53:19 [5552] Interrupted by Close
20210118 15:53:19 [4692] downing servmgr...
20210118 15:53:19 [5884] done (from 1:229/427@fidonet, failed, S/R: 0/0 (0/0
bytes)
20210118 15:53:19 [5884] receiving of X1-240~1.SNA interrupted at 13475840
20210118 15:53:19 [5884] session closed, quitting...
Nick
--- Renegade vY2Ka2
* Origin: Joey, do you like movies about gladiators? (1:229/426)
Re: Re: Semaphore
By: Nick Andre to Rob Swindell on Mon Jan 18 2021 03:57 pm
> On 18 Jan 21 12:31:02, Rob Swindell said the following to Nick Andre:
>
> RS> Looking at the source code, it appears that BinkD already behaves
> RS> exactly a you are requesting it to behave: When it receives SIGBREAK,
> RS> SIGINT, or SIGTERM, it sets the 'binkd_exit' global flag and then
> RS> terminates when idle that flag is set.
>
> Nope, it does not appear to function this way on Windows. Set up a test
> transaction of a large file just over 300 meg. Close with Taskkill. Active
> session closes and notes a failure in the log... not terminating on "idle".
>
> 20210118 15:53:15 [5884] Remote has 0b of mail and 335278080b of files for
> us 20210118 15:53:15 [5884] pwd protected session (MD5)
> 20210118 15:53:15 [5884] session in CRYPT mode
> 20210118 15:53:15 [5884] receiving X1-240~1.SNA (335278080 byte(s), off 0)
> 20210118 15:53:19 [5552] Interrupted by Close
> 20210118 15:53:19 [4692] downing servmgr...
> 20210118 15:53:19 [5884] done (from 1:229/427@fidonet, failed, S/R: 0/0 (0/0
> bytes)
> 20210118 15:53:19 [5884] receiving of X1-240~1.SNA interrupted at 13475840
> 20210118 15:53:19 [5884] session closed, quitting...
Ah, the Windows code has a forked version of that breaksig.c file:
https://github.com/pgul/binkd/blob/master/nt/breaksig.c
Notice how nothing sets 'binkd_exit' in there?
Looks like the deferred exit upon termination was a feature that was added and
then never ported to the Windows build of BinkD.
A likely fix would be:
case CTRL_CLOSE_EVENT:
Log (1, "Interrupted by Close");
binkd_exit = TRUE;
return TRUE;
--
digital man
Synchronet "Real Fact" #20:
Michael Swindell was directly responsible for Synchronet's commercial success.
--- SBBSecho 3.12-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
By: Nick Andre to Rob Swindell on Mon Jan 18 2021 03:57 pm
> On 18 Jan 21 12:31:02, Rob Swindell said the following to Nick Andre:
>
> RS> Looking at the source code, it appears that BinkD already behaves
> RS> exactly a you are requesting it to behave: When it receives SIGBREAK,
> RS> SIGINT, or SIGTERM, it sets the 'binkd_exit' global flag and then
> RS> terminates when idle that flag is set.
>
> Nope, it does not appear to function this way on Windows. Set up a test
> transaction of a large file just over 300 meg. Close with Taskkill. Active
> session closes and notes a failure in the log... not terminating on "idle".
>
> 20210118 15:53:15 [5884] Remote has 0b of mail and 335278080b of files for
> us 20210118 15:53:15 [5884] pwd protected session (MD5)
> 20210118 15:53:15 [5884] session in CRYPT mode
> 20210118 15:53:15 [5884] receiving X1-240~1.SNA (335278080 byte(s), off 0)
> 20210118 15:53:19 [5552] Interrupted by Close
> 20210118 15:53:19 [4692] downing servmgr...
> 20210118 15:53:19 [5884] done (from 1:229/427@fidonet, failed, S/R: 0/0 (0/0
> bytes)
> 20210118 15:53:19 [5884] receiving of X1-240~1.SNA interrupted at 13475840
> 20210118 15:53:19 [5884] session closed, quitting...
Ah, the Windows code has a forked version of that breaksig.c file:
https://github.com/pgul/binkd/blob/master/nt/breaksig.c
Notice how nothing sets 'binkd_exit' in there?
Looks like the deferred exit upon termination was a feature that was added and
then never ported to the Windows build of BinkD.
A likely fix would be:
case CTRL_CLOSE_EVENT:
Log (1, "Interrupted by Close");
binkd_exit = TRUE;
return TRUE;
--
digital man
Synchronet "Real Fact" #20:
Michael Swindell was directly responsible for Synchronet's commercial success.
--- SBBSecho 3.12-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
On 19 Jan 21 09:56:27, Dan Cross said the following to Dallas Hinton:
DC> More generally, the issue in this discussion is that the
DC> request for a feature has been wrapped up in details about
DC> the implementation of that feature. From my observation,
DC> that's the central source of friction.
I cannot believe I actually agree with Oli about something but he is 100%
correct that its likely because the request is DOS-ish and not Posix-ish.
The use of signals I can and have clearly demonstrated that it works
differently on Windows. I believe Rob when he tells me the logic is there, he
may be correct but BinkD on Windows drops all active connections when
signalled. If someone can demonstrate a way to fulfill the request, wonderful.
I don't buy that argument of introducing another level of complexity because
the BinkD code is already doing a fair amount of checking for files such as
the config, FLO, HLD etc. Checking for a dummy file cannot be much of a
stretch to put in there. Its a silly program that sends silly Fido packets;
its not some mission-critical airline reservation system.
Anyhow its not the end of the world if it can't be done but the reactions to
this simple request from Sysops over the years are almost always negative from
a certain OS crowd.
Nick
--- Renegade vY2Ka2
* Origin: Joey, do you like movies about gladiators? (1:229/426)
DC> More generally, the issue in this discussion is that the
DC> request for a feature has been wrapped up in details about
DC> the implementation of that feature. From my observation,
DC> that's the central source of friction.
I cannot believe I actually agree with Oli about something but he is 100%
correct that its likely because the request is DOS-ish and not Posix-ish.
The use of signals I can and have clearly demonstrated that it works
differently on Windows. I believe Rob when he tells me the logic is there, he
may be correct but BinkD on Windows drops all active connections when
signalled. If someone can demonstrate a way to fulfill the request, wonderful.
I don't buy that argument of introducing another level of complexity because
the BinkD code is already doing a fair amount of checking for files such as
the config, FLO, HLD etc. Checking for a dummy file cannot be much of a
stretch to put in there. Its a silly program that sends silly Fido packets;
its not some mission-critical airline reservation system.
Anyhow its not the end of the world if it can't be done but the reactions to
this simple request from Sysops over the years are almost always negative from
a certain OS crowd.
Nick
--- Renegade vY2Ka2
* Origin: Joey, do you like movies about gladiators? (1:229/426)
Re: Re: Semaphore
By: Nick Andre to Dan Cross on Mon Jan 18 2021 04:33 pm
> On 19 Jan 21 09:56:27, Dan Cross said the following to Dallas Hinton:
>
> DC> More generally, the issue in this discussion is that the
> DC> request for a feature has been wrapped up in details about
> DC> the implementation of that feature. From my observation,
> DC> that's the central source of friction.
>
> I cannot believe I actually agree with Oli about something but he is 100%
> correct that its likely because the request is DOS-ish and not Posix-ish.
>
> The use of signals I can and have clearly demonstrated that it works
> differently on Windows. I believe Rob when he tells me the logic is there,
> he may be correct but BinkD on Windows drops all active connections when
> signalled. If someone can demonstrate a way to fulfill the request,
> wonderful.
Try this:
ftp://vert.synchro.net/main/bbs/binkd.exe
You can see the (2 line) code change here:
https://github.com/rswindell/binkd/commit/68baf454683688b52890ab3ce9e9f403
If it works as you wish, I'll submit a PR to pgul's repo.
> I don't buy that argument of introducing another level of complexity because
> the BinkD code is already doing a fair amount of checking for files such as
> the config, FLO, HLD etc. Checking for a dummy file cannot be much of a
> stretch to put in there. Its a silly program that sends silly Fido packets;
> its not some mission-critical airline reservation system.
BinkD is a unixy program and semaphore files are just not the Unixy-way (for a
lot of good reasons). The *nix build of BinkD already behaves in the way you
requested, so perhaps that added to the confusion. Or maybe the primary
contributors aren't actively following this echo.
> Anyhow its not the end of the world if it can't be done but the reactions to
> this simple request from Sysops over the years are almost always negative
> from a certain OS crowd.
Huh.
--
digital man
Sling Blade quote #5:
Karl Childers (to father): You ought not killed my little brother...
--- SBBSecho 3.12-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
By: Nick Andre to Dan Cross on Mon Jan 18 2021 04:33 pm
> On 19 Jan 21 09:56:27, Dan Cross said the following to Dallas Hinton:
>
> DC> More generally, the issue in this discussion is that the
> DC> request for a feature has been wrapped up in details about
> DC> the implementation of that feature. From my observation,
> DC> that's the central source of friction.
>
> I cannot believe I actually agree with Oli about something but he is 100%
> correct that its likely because the request is DOS-ish and not Posix-ish.
>
> The use of signals I can and have clearly demonstrated that it works
> differently on Windows. I believe Rob when he tells me the logic is there,
> he may be correct but BinkD on Windows drops all active connections when
> signalled. If someone can demonstrate a way to fulfill the request,
> wonderful.
Try this:
ftp://vert.synchro.net/main/bbs/binkd.exe
You can see the (2 line) code change here:
https://github.com/rswindell/binkd/commit/68baf454683688b52890ab3ce9e9f403
If it works as you wish, I'll submit a PR to pgul's repo.
> I don't buy that argument of introducing another level of complexity because
> the BinkD code is already doing a fair amount of checking for files such as
> the config, FLO, HLD etc. Checking for a dummy file cannot be much of a
> stretch to put in there. Its a silly program that sends silly Fido packets;
> its not some mission-critical airline reservation system.
BinkD is a unixy program and semaphore files are just not the Unixy-way (for a
lot of good reasons). The *nix build of BinkD already behaves in the way you
requested, so perhaps that added to the confusion. Or maybe the primary
contributors aren't actively following this echo.
> Anyhow its not the end of the world if it can't be done but the reactions to
> this simple request from Sysops over the years are almost always negative
> from a certain OS crowd.
Huh.
--
digital man
Sling Blade quote #5:
Karl Childers (to father): You ought not killed my little brother...
--- SBBSecho 3.12-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
On 18 Jan 2021 at 04:33p, Nick Andre pondered and said...
NA> I cannot believe I actually agree with Oli about something but he is
NA> 100% correct that its likely because the request is DOS-ish and not
NA> Posix-ish.
I dunno. Do you care about the feature or how the feature is
implemented? Seems like the former is more important than the
latter. I've tried pretty hard to be respectful here; but I'm
just an old-time Unix person. *shrug*
--- Mystic BBS v1.12 A46 2020/08/26 (Windows/32)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (3:770/100)
NA> I cannot believe I actually agree with Oli about something but he is
NA> 100% correct that its likely because the request is DOS-ish and not
NA> Posix-ish.
I dunno. Do you care about the feature or how the feature is
implemented? Seems like the former is more important than the
latter. I've tried pretty hard to be respectful here; but I'm
just an old-time Unix person. *shrug*
--- Mystic BBS v1.12 A46 2020/08/26 (Windows/32)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (3:770/100)
On 19 Jan 21 12:23:10, Dan Cross said the following to Nick Andre:
DC> NA> I cannot believe I actually agree with Oli about something but he is
DC> NA> 100% correct that its likely because the request is DOS-ish and not
DC> NA> Posix-ish.
DC>
DC> I dunno. Do you care about the feature or how the feature is
DC> implemented? Seems like the former is more important than the
Not really. I care that the feature works. Rob appears to of found the problem
in the code.
Nick
--- Renegade vY2Ka2
* Origin: Joey, do you like movies about gladiators? (1:229/426)
DC> NA> I cannot believe I actually agree with Oli about something but he is
DC> NA> 100% correct that its likely because the request is DOS-ish and not
DC> NA> Posix-ish.
DC>
DC> I dunno. Do you care about the feature or how the feature is
DC> implemented? Seems like the former is more important than the
Not really. I care that the feature works. Rob appears to of found the problem
in the code.
Nick
--- Renegade vY2Ka2
* Origin: Joey, do you like movies about gladiators? (1:229/426)
On 18 Jan 2021 at 06:29p, Nick Andre pondered and said...
NA> Not really. I care that the feature works. Rob appears to of found the
NA> problem in the code.
Problem solved. Yay!
--- Mystic BBS v1.12 A46 2020/08/26 (Windows/32)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (3:770/100)
NA> Not really. I care that the feature works. Rob appears to of found the
NA> problem in the code.
Problem solved. Yay!
--- Mystic BBS v1.12 A46 2020/08/26 (Windows/32)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (3:770/100)
On 18 Jan 21 16:28:58, Rob Swindell said the following to Richard Menedetter:
> Great!
> Would it be possible to push that into the official repo?
RS>
RS> If someone can confirm it works as desired (I don't actually use binkd any
RS> longer), I'll submit the pull request to the official repo.
I'll try to confirm this by sometime tomorrow. Thank you.
Nick
--- Renegade vY2Ka2
* Origin: Joey, do you like movies about gladiators? (1:229/426)
> Great!
> Would it be possible to push that into the official repo?
RS>
RS> If someone can confirm it works as desired (I don't actually use binkd any
RS> longer), I'll submit the pull request to the official repo.
I'll try to confirm this by sometime tomorrow. Thank you.
Nick
--- Renegade vY2Ka2
* Origin: Joey, do you like movies about gladiators? (1:229/426)
-=> On 01-17-21 12:50, Nick Andre wrote to Wilfred Van Velzen <=-
NA> I asked for the same thing over the years. I'm wondering why the
NA> arrogance insist that we kill things by Pid instead of telling the
NA> program to exit gracefully. The program checks for modifcations to the
NA> config file; it could easily just check for a dummy file and close up
NA> shop.
"kill" by default sends a SIGTERM to the process, which tells it to shut down
gracefully. At least on a *NIX OS.
... Don't itch for what you don't intend to scratch.
=== MultiMail/Win v0.52
--- SBBSecho 3.10-Linux
* Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (3:633/410)
NA> I asked for the same thing over the years. I'm wondering why the
NA> arrogance insist that we kill things by Pid instead of telling the
NA> program to exit gracefully. The program checks for modifcations to the
NA> config file; it could easily just check for a dummy file and close up
NA> shop.
"kill" by default sends a SIGTERM to the process, which tells it to shut down
gracefully. At least on a *NIX OS.
... Don't itch for what you don't intend to scratch.
=== MultiMail/Win v0.52
--- SBBSecho 3.10-Linux
* Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (3:633/410)