Is it possible to code in (in a future release) a mechanism to make
binkd exit (shut down) by seeing a semaphore in a given directory? Internet Rex had this, when it saw "REXEXIT.NOW" in the semaphore directory.
Hi Marc,
On 2021-01-17 09:20:03, you wrote to All:
Is it possible to code in (in a future release) a mechanism to
make binkd exit (shut down) by seeing a semaphore in a given
directory? Internet Rex had this, when it saw "REXEXIT.NOW" in
the semaphore directory.
I'm wondering why you would need that?
And doesn't OS2 have a way to kill running software? In linux you can
'kill' it by PID or program name, so you don't need a semaphore file
for this kind of mechanism...
Is it possible to code in (in a future release) a mechanism to make binkd exit (shut down) by seeing a semaphore in a given directory? Internet Rex had this, when it saw "REXEXIT.NOW" in the semaphore directory.
I'm wondering why you would need that?
And doesn't OS2 have a way to kill running software? In linux you can 'kill it by PID or program name, so you don't need a semaphore file for this kind mechanism...
On 2021-01-17 09:20:03, you wrote to All:
Is it possible to code in (in a future release) a mechanism to make
binkd exit (shut down) by seeing a semaphore in a given directory?
Internet Rex had this, when it saw "REXEXIT.NOW" in the semaphore
directory.
I'm wondering why you would need that?
And doesn't OS2 have a way to kill running software?
Is it possible to code in (in a future release) a mechanism to make
binkd exit (shut down) by seeing a semaphore in a given directory?
Internet Rex had this, when it saw "REXEXIT.NOW" in the semaphore
directory.
I'm wondering why you would need that?
I asked for the same thing over the years. I'm wondering why the arrogance insist that we kill things by Pid instead of telling the program to exit gracefully.
I asked for the same thing over the years. I'm wondering why the arrog insist that we kill things by Pid instead of telling the program to ex gracefully.
Maybe "to kill" is a bit wrong. Terminating a program with PID is "to ask t stop".
And doesn't OS2 have a way to kill running software? In linux you can 'kill it by PID or program name, so you don't need a semaphore file for this kind mechanism...
When your beloved Linux needs to shut down, why does it not just immediately signal the system to power off? Why does it get busy terminating services?
Is it possible to code in (in a future release) a mechanism to make
binkd exit (shut down) by seeing a semaphore in a given directory? Internet Rex had this, when it saw "REXEXIT.NOW" in the semaphore directory.
I'm wondering why you would need that?
And doesn't OS2 have a way to kill running software? In linux you
can 'kill' it by PID or program name, so you don't need a
semaphore file for this kind of mechanism...
When your beloved Linux needs to shut down, why does it not just immediately signal the system to power off? Why does it get busy terminating services?
Programs can handle signals (e.g. SIGTERM) gracefully. This is pretty stand for *nix programs and BinkD is no exception. This is what the exitsig() function in binkd's breaksig.c already does.
On 17 Jan 21 12:41:01, Rob Swindell said the following to Nick Andre:
When your beloved Linux needs to shut down, why does it not just immediately signal the system to power off? Why does it get busy terminating services?
Programs can handle signals (e.g. SIGTERM) gracefully. This is pretty stand for *nix programs and BinkD is no exception. This is what the exitsig() function in binkd's breaksig.c already does.
Yes... I already know this. Thats not what was requested here a few times over the years. Read my other message. Dialup/legacy/other mailers wait until the current session is done before exiting when receiving an exit semaphore.
Okay, so you're wanting a change in the behavior of the termination signal handling. That seems different than expecting the use of a file to signal t termination.
On 17 Jan 21 13:37:37, Rob Swindell said the following to Nick Andre:
Okay, so you're wanting a change in the behavior of the termination signal handling. That seems different than expecting the
use of a file to signal t termination.
Nope.
What was asked was an additional check for a simple dummy file when BinkD ***is idle*** and terminates if that file exists.
I prefer to have all connections finish before BinkD shuts down.... letting the door close gently via a dummy file rather than
slamming it shut with Pid.
Just like every Fidonet mailer does so.
There are many standard signals and BinkD is treating 3 of them the same (SIGBREAK, SIGINT, and SIGTERM). It doesn't seem like it would be hard to change the behavior of one or all of those (or add support for another signal) to terminate in the fashion you're requesting. Without the use
of a file.
On 17 Jan 2021 at 01:37p, Rob Swindell pondered and said...
There are many standard signals and BinkD is treating 3 of them the same (SIGBREAK, SIGINT, and SIGTERM). It doesn't seem like it would be hard to change the behavior of one or all of those (or add support for another signal) to terminate in the fashion you're requesting. Without the use
of a file.
I nominate "SIGQUIT".
The use of a file seems like an unnecessary DOS-ism.
What was asked was an additional check for a simple dummy file when
BinkD ***is idle*** and terminates if that file exists.
I prefer to have all connections finish before BinkD shuts down....
letting the door close gently via a dummy file rather than slamming it shut with Pid.
Hello All.
Is it possible to code in (in a future release) a mechanism to make binkd exit (shut down) by seeing a semaphore in a given directory? Internet Rex had this, when it saw "REXEXIT.NOW" in the semaphore directory.
I assume that for some people it sounds very strange to implement an exit file semaphore in 2021.
So they don't do it, as they do not see any benefit in it.
I assume that for some people it sounds very strange to implementI didn't know that anyone has implemented any new feature in the last couple of years.
an exit file semaphore in 2021.
So they don't do it, as they do not see any benefit in it.Who are they?
Is it possible to code in (in a future release) a mechanism to make
binkd exit (shut down) by seeing a semaphore in a given directory?
Internet Rex had this, when it saw "REXEXIT.NOW" in the semaphore
directory.
I'm wondering why you would need that?
And doesn't OS2 have a way to kill running software? In linux you
can 'kill' it by PID or program name, so you don't need a
semaphore file for this kind of mechanism...
I'll do some command digging and see; there probably IS a type of 'kill' command built into OS/2 that
I've never utilised.
Yeah, you're not understanding what I'm saying. BinkD could pretty easily s a flag when it receives a signal (whatever signal, it doesn't have to be SIGTERM) and then terminate ***when idle**. It sounds like you're opposed t the use of a signal for some reasson.
I have not checked how BinkD reacts to SIGTERM
letting the door close gently via a dummy file rather than slamming it shut with Pid.
There are MANY SIGNALS!!!!!
What I "don't understand" is the apparent
visceral reaction by some to have that same simple level of functionality as the rest. The mere suggestion just gets everyone's rulers out to measure how big their Linux egos are.
I wonder in which way signals are better in contrast to a semaphore from a usability / user's perspective? Yes, signals are useful, but in this specifi case? What's wrong with a semaphore (besides that it's not hip in 2021)?
If the initial request can be done, I'm all ears. If it cannot, then
life goes on. Its not the end of the world.
I nominate "SIGQUIT".
SIGQUIT normally triggers a core dump (the default "action" if no signal handler is installed). Probably not the best choice for the proposed use case.
Yup. That's what I was trying to say. :-)
If the goalposts don't get moved after that, then we go back to the strawman game of "Its open source, add the feature yourself".
I wonder in which way signals are better in contrast to a semaphore from
a usability / user's perspective? Yes, signals are useful, but in this specific case? What's wrong with a semaphore (besides that it's not hip
in 2021)?
A couple of things, but the biggest one I can think of is fragility
in the face of system crashes. In particular, who's responsible for cleaning this file up? Should `binkd` delete it as part of gracefully
On 17 Jan 21 18:42:46, Rob Swindell said the following to Nick Andre:
Yeah, you're not understanding what I'm saying. BinkD could pretty easily s a flag when it receives a signal (whatever signal, it doesn't have to be SIGTERM) and then terminate ***when idle**. It sounds like you're opposed t the use of a signal for some reasson.
Yeah, I'm not opposed to signals.
Its not that difficult to understand the
intention of the request. This is a very busy Hub system where I'd like to schedule maintainence when BinkD twiddles its thumbs. Whether thats done with semaphore files or signals doesn't matter to me. If someone shows me how to accomplish my request on Windows then wonderful... that person gets simple kudos and the echo goes back to crickets chirping.
That said, traditional or legacy mailers on DOS, Windows and OS/2 have always reacted to semaphore files. My software, Frontdoor, Intermail, TBBS/Flame,
etc. as well as Internet Rex. What I "don't understand" is the apparent visceral reaction by some to have that same simple level of functionality as the rest. The mere suggestion just gets everyone's rulers out to measure how big their Linux egos are.
Its been running here for many years trouble-free... its not the end of the world if it can't do one little thing. Any further discussion or quote-rants or whatever silly symantecs and we have to cough up royalties to Mark Lewis.
Yeah, I'm not opposed to signals. Its not that difficult to understand the intention of the request. This is a very busy Hub system where I'd like to schedule maintainence when BinkD twiddles its thumbs. Whether thats done with semaphore files or signals doesn't matter to me. If someone shows me how to accomplish my request on Windows then wonderful... that person gets simple kudos and the echo goes back to crickets chirping.
Its been running here for many years trouble-free... its not the end of the world if it can't do one little thing. Any further discussion or quote-rants or whatever silly symantecs and we have to cough up royalties to Mark Lewis.
It wouldn't be a big change to binkd and it's open source. Try addig it (starting with breaksig.c), if you need help, just ask.
https://www.computerhope.com/taskkill.htm
On 18 Jan 21 12:06:52, Rob Swindell said the following to Nick Andre:
https://www.computerhope.com/taskkill.htm
Already tried that. Kills BinkD and all active connections.
Hi, Dan -- on Jan 19 2021 at 03:11, you wrote:
A couple of things, but the biggest one I can think of is fragility
in the face of system crashes. In particular, who's responsible for cleaning this file up? Should `binkd` delete it as part of gracefully
FWIW, I have a batch file that runs on startup and deletes all semaphore flags. They're all in the same directory so it's easy.
Looking at the source code, it appears that BinkD already behaves exactly a you are requesting it to behave: When it receives SIGBREAK, SIGINT, or SIGTERM, it sets the 'binkd_exit' global flag and then terminates when idle that flag is set.
On 18 Jan 21 12:31:02, Rob Swindell said the following to Nick Andre:
Looking at the source code, it appears that BinkD already behaves exactly a you are requesting it to behave: When it receives SIGBREAK, SIGINT, or SIGTERM, it sets the 'binkd_exit' global flag and then 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...
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.
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
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.
On 19 Jan 21 09:56:27, Dan Cross said the following to Dallas Hinton:
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.
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.
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.
Nope, it does not appear to function this way on Windows.
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.
I dunno. Do you care about the feature or how the feature is
implemented? Seems like the former is more important than the
You can see the (2 line) code change here: https://github.com/rswindell/binkd/commit/68baf454683688b52890ab3ce9e9 f403
Not really. I care that the feature works. Rob appears to of found the problem in the code.
Hi Rob!
18 Jan 2021 14:14, from Rob Swindell -> Nick Andre:
You can see the (2 line) code change here: https://github.com/rswindell/binkd/commit/68baf454683688b52890ab3ce9e9 f403
Great!
Would it be possible to push that into the official repo?
Great!
Would it be possible to push that into the official repo?
If someone can confirm it works as desired (I don't actually use binkd any longer), I'll submit the pull request to the official repo.
Would it be possible to push that into the official repo?If someone can confirm it works as desired (I don't actually use binkd
any longer), I'll submit the pull request to the official repo.
On 01-17-21 12:50, Nick Andre wrote to Wilfred Van Velzen <=-
I asked for the same thing over the years. I'm wondering why the
arrogance insist that we kill things by Pid instead of telling the
program to exit gracefully. The program checks for modifcations to the config file; it could easily just check for a dummy file and close up shop.
| Sysop: | digital man |
|---|---|
| Location: | Riverside County, California |
| Users: | 1,050 |
| Nodes: | 15 (1 / 14) |
| Uptime: | 58:28:20 |
| Calls: | 236,055 |
| Calls today: | 3 |
| Files: | 60,364 |
| D/L today: |
50 files (53,939K bytes) |
| Messages: | 289,757 |