Fidonet Portal






From: Marc Lewis (1:396/45)
To: All
Date: Sun, 17.01.21 10:20
Semaphore
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.

....Otherwise, binkd (for OS/2) works like an absolute champ.

Best regards,
Marc

--- timEd/2 1.10.y2k+
* Origin: Sursum Corda! BBS-Huntsville,AL-bbs.sursum-corda.com (1:396/45)

From: Wilfred van Velzen (2:280/464)
To: All
Date: Sun, 17.01.21 17:54
Re: Semaphore
Hi Marc,

On 2021-01-17 09:20:03, you wrote to All:

ML> Is it possible to code in (in a future release) a mechanism to make
ML> binkd exit (shut down) by seeing a semaphore in a given directory?
ML> Internet Rex had this, when it saw "REXEXIT.NOW" in the semaphore
ML> 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...

Bye, Wilfred.

--- FMail-lnx64 2.1.0.18-B20170815
* Origin: FMail development HQ (2:280/464)

From: Nick Andre (1:229/426)
To: All
Date: Sun, 17.01.21 13:50
Re: Semaphore
On 17 Jan 21 16:54:11, Wilfred Van Velzen said the following to Marc Lewis:

WV> ML> Is it possible to code in (in a future release) a mechanism to make
WV> ML> binkd exit (shut down) by seeing a semaphore in a given directory?
WV> ML> Internet Rex had this, when it saw "REXEXIT.NOW" in the semaphore
WV> ML> directory.
WV>
WV> 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. The program checks for modifcations to the config file; it could
easily just check for a dummy file and close up shop.

WV> And doesn't OS2 have a way to kill running software? In linux you can 'kill
WV> it by PID or program name, so you don't need a semaphore file for this kind
WV> 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?

Nick

--- Renegade vY2Ka2
* Origin: Joey, do you like movies about gladiators? (1:229/426)

From: Nick Andre (1:229/426)
To: All
Date: Sun, 17.01.21 14:29
Re: Semaphore
On 17 Jan 21 20:07:26, Tommi Koivula said the following to Nick Andre:

TK> NA> I asked for the same thing over the years. I'm wondering why the arrog
TK> NA> insist that we kill things by Pid instead of telling the program to ex
TK> NA> gracefully.
TK>
TK> Maybe "to kill" is a bit wrong. Terminating a program with PID is "to ask t
TK> stop".

I know what it means and those of us who asked for a shutdown-semaphore
want slightly different behavior than terminating with Pid.

On typical Fido mailers, you create an exit semaphore so the mailer sees that
and exits with an errorlevel set once the current mail session has ended. On
BinkD (on Windows) telling it to close terminates active connections.

This has been requested here a few times.

Nick

--- Renegade vY2Ka2
* Origin: Joey, do you like movies about gladiators? (1:229/426)

From: Rob Swindell (1:103/705)
To: All
Date: Sun, 17.01.21 13:41
Re: Semaphore
Re: Re: Semaphore
By: Nick Andre to Wilfred Van Velzen on Sun Jan 17 2021 12:50 pm

> WV> And doesn't OS2 have a way to kill running software? In linux you can
> WV> 'kill it by PID or program name, so you don't need a semaphore file for
> WV> 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?

Programs can handle signals (e.g. SIGTERM) gracefully. This is pretty standard
for *nix programs and BinkD is no exception. This is what the exitsig(Wink
function in binkd's breaksig.c already does.
--
digital man

Synchronet/BBS Terminology Definition #18:
DCD = Data Carrier Detect

--- SBBSecho 3.12-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

From: Marc Lewis (1:396/45)
To: All
Date: Sun, 17.01.21 15:35
RE: Semaphore
Hello Wilfred.

<On 17Jan2021 16:54 Wilfred van Velzen (2:280/464) wrote a message to Marc
Lewis regarding Re: Semaphore >

ML> Is it possible to code in (in a future release) a mechanism to make
ML> binkd exit (shut down) by seeing a semaphore in a given directory?
ML> Internet Rex had this, when it saw "REXEXIT.NOW" in the semaphore
ML> directory.

WvV> I'm wondering why you would need that?

WvV> And doesn't OS2 have a way to kill running software? In linux you
WvV> can 'kill' it by PID or program name, so you don't need a
WvV> 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.

Best regards,
Marc

... !Updating Windows - - DO NOT TURN ON YOUR COMPUTER.
--- timEd/2 1.10.y2k+
* Origin: Sursum Corda! BBS-Huntsville,AL-bbs.sursum-corda.com (1:396/45)

From: Nick Andre (1:229/426)
To: All
Date: Sun, 17.01.21 16:46
Re: Semaphore
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?
RS>
RS> Programs can handle signals (e.g. SIGTERM) gracefully. This is pretty stand
RS> for *nix programs and BinkD is no exception. This is what the exitsig(Wink
RS> 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.

Nick

--- Renegade vY2Ka2
* Origin: Joey, do you like movies about gladiators? (1:229/426)

From: Rob Swindell (1:103/705)
To: All
Date: Sun, 17.01.21 14:37
Re: Semaphore
Re: Re: Semaphore
By: Nick Andre to Rob Swindell on Sun Jan 17 2021 03:46 pm

> 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?
>
> RS> Programs can handle signals (e.g. SIGTERM) gracefully. This is pretty
> RS> stand for *nix programs and BinkD is no exception. This is what the
> RS> exitsig(Wink 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 the
termination.

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.
--
digital man

Sling Blade quote #12:
Karl (re hammer): I don't rightly know. I just kinda woke up holding it.

--- SBBSecho 3.12-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

From: Nick Andre (1:229/426)
To: All
Date: Sun, 17.01.21 19:27
Re: Semaphore
On 17 Jan 21 13:37:37, Rob Swindell said the following to Nick Andre:

RS> Okay, so you're wanting a change in the behavior of the termination signal
RS> handling. That seems different than expecting the use of a file to signal t
RS> 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.

Nick

--- Renegade vY2Ka2
* Origin: Joey, do you like movies about gladiators? (1:229/426)

From: Rob Swindell (1:103/705)
To: All
Date: Sun, 17.01.21 19:42
Re: Semaphore
Re: Re: Semaphore
By: Nick Andre to Rob Swindell on Sun Jan 17 2021 06:27 pm

> On 17 Jan 21 13:37:37, Rob Swindell said the following to Nick Andre:
>
> RS> Okay, so you're wanting a change in the behavior of the termination
signal handling. That seems different than expecting the
> RS> 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.

Yeah, you're not understanding what I'm saying. BinkD could pretty easily set 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 to the use of
a signal for some reasson.

> Just like every Fidonet mailer does so.

BinkIT is a FidoNet mailer and does not behave as you describe.
--
digital man

This Is Spinal Tap quote #33:
Nigel Tufnel: Well, so what? What's wrong with bein' sexy?

--- SBBSecho 3.12-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

From: Dan Cross (3:770/100)
To: All
Date: Mon, 18.01.21 16:48
Re: Semaphore
On 17 Jan 2021 at 01:37p, Rob Swindell pondered and said...

RS> There are many standard signals and BinkD is treating 3 of them the same
RS> (SIGBREAK, SIGINT, and SIGTERM). It doesn't seem like it would be hard to
RS> change the behavior of one or all of those (or add support for another
RS> signal) to terminate in the fashion you're requesting. Without the use
RS> of a file.

I nominate "SIGQUIT". The use of a file seems like
an unnecessary DOS-ism.

--- Mystic BBS v1.12 A46 2020/08/26 (Windows/32)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (3:770/100)

From: Rob Swindell (1:103/705)
To: All
Date: Sun, 17.01.21 21:09
Re: Semaphore
Re: Re: Semaphore
By: Dan Cross to Rob Swindell on Mon Jan 18 2021 03:48 pm

> On 17 Jan 2021 at 01:37p, Rob Swindell pondered and said...
>
> RS> There are many standard signals and BinkD is treating 3 of them the
> RS> same (SIGBREAK, SIGINT, and SIGTERM). It doesn't seem like it would be
> RS> hard to change the behavior of one or all of those (or add support for
> RS> another signal) to terminate in the fashion you're requesting. Without
> RS> the use
> RS> of a file.
>
> 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.

> The use of a file seems like an unnecessary DOS-ism.

Yup. That's what I was trying to say. Smile
--
digital man

This Is Spinal Tap quote #18:
Sustain, listen to it. Don't hear anything. You would though were it playing.

--- SBBSecho 3.12-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

From: Nick Andre (1:229/426)
To: All
Date: Mon, 18.01.21 06:20
Re: Semaphore
On 17 Jan 21 18:42:46, Rob Swindell said the following to Nick Andre:

RS> Yeah, you're not understanding what I'm saying. BinkD could pretty easily s
RS> a flag when it receives a signal (whatever signal, it doesn't have to be
RS> SIGTERM) and then terminate ***when idle**. It sounds like you're opposed t
RS> 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.

Nick

--- Renegade vY2Ka2
* Origin: Joey, do you like movies about gladiators? (1:229/426)

From: Nick Andre (1:229/426)
To: All
Date: Mon, 18.01.21 06:23
Re: Semaphore
On 18 Jan 21 10:33:20, Richard Menedetter said the following to Nick Andre:

RM> I have not checked how BinkD reacts to SIGTERM

As explained - Myself and others have a specific need to have BinkD shutdown
when its idle. As in, after all connections finish up. I really don't care at
the end of the day if that is accomplished with a semaphore file or other
means so long as it does things exactly in the way that was being described.

RM> NA> letting the door close gently via a dummy file rather than slamming it
RM> NA> shut with Pid.
RM>
RM> There are MANY SIGNALS!!!!!

BinkD runs excellent on this Windows system for long periods of uptime
unattended without any babysitting. 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.

If I wasn't happy with it, I wouldn't be using it. Calm down, have some dip.

Nick

--- Renegade vY2Ka2
* Origin: Joey, do you like movies about gladiators? (1:229/426)

From: Nick Andre (1:229/426)
To: All
Date: Mon, 18.01.21 07:56
Re: Semaphore
On 18 Jan 21 12:47:19, Oli said the following to Nick Andre:

O> I wonder in which way signals are better in contrast to a semaphore from a
O> usability / user's perspective? Yes, signals are useful, but in this specifi
O> case? What's wrong with a semaphore (besides that it's not hip in 2021)?

I have yet to have that simple question answered to me logically, politely,
step-by-step without someone bragging about the size of their Linux penis.

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 think I'll use that line whenever I encounter a Linux guy who can't make a
piece of hardware work correctly as it does on Windows.

Nick

--- Renegade vY2Ka2
* Origin: Joey, do you like movies about gladiators? (1:229/426)

From: Dan Cross (3:770/100)
To: All
Date: Tue, 19.01.21 03:55
Re: Semaphore
On 17 Jan 2021 at 08:09p, Rob Swindell pondered and said...

RS> > I nominate "SIGQUIT".
RS>
RS> SIGQUIT normally triggers a core dump (the default "action" if no signal
RS> handler is installed). Probably not the best choice for the proposed use
RS> case.

Indeed, but since you're overriding the default action with a custom
signal handler anyway, why not?

RS> Yup. That's what I was trying to say. Smile

And I agree with you. Smile

--- Mystic BBS v1.12 A46 2020/08/26 (Windows/32)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (3:770/100)

From: Dan Cross (3:770/100)
To: All
Date: Tue, 19.01.21 04:11
Re: Semaphore
On 18 Jan 2021 at 12:47p, Oli pondered and said...

Ol> I wonder in which way signals are better in contrast to a semaphore from
Ol> a usability / user's perspective? Yes, signals are useful, but in this
Ol> specific case? What's wrong with a semaphore (besides that it's not hip
Ol> 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
exiting? What happens if the file exists when `binkd` restarts?
That is, even if `binkd` is responsible for deleting the file, it's
possible that the system may crash in between it being created and
`binkd` cleaning it up, so `binkd` may observe the presence of the
file when it next starts up again. Should it delete it, or refuse
to continue running?

Generally speaking, the use of a "semaphore" file (what a terrible
name) conflates the concept of issuing a control operation to some
long-running process (which is precisely what things like signals
are for) with the persistence of data provided by a filesystem.
But processes are by their nature ephemeral: they only have meaning
while running. Once they've stopped running, that's it; there's
no mechanism to continue controlling them. It muddies things and
unnecessarily widens the design space (forcing one to confront issues
like the above) for no apparent reason other than that's what someone
suggested.

It's clear from context that what the OP _really_ wants is just some
mechanism to signal `binkd` that it should gracefully exit once it's
done processing its current queue of work for existing connections;
implicit in this, it should _also_ deny new incoming connections and
refrain from making new outgoing connections. In other words, it
should lame-duck and quiesce itself and then exit. That's fine, and
seems reasonable. The issue is that the request for enhancement didn't
say _that_, instead, it was written in terms of using this file-based
mechanism for signaling, when a perfectly good signaling mechanism
already exists and is implemented almost everywhere.

Synchronizing on files as a poor-man's IPC mechanism seems strange
when the system provides any number of existing IPC mechanisms one
can use instead. In particular, signals were invented for
precisely this kind of signaling.

--- Mystic BBS v1.12 A46 2020/08/26 (Windows/32)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (3:770/100)

From: Rob Swindell (1:103/705)
To: All
Date: Mon, 18.01.21 13:06
Re: Semaphore
Re: Re: Semaphore
By: Nick Andre to Rob Swindell on Mon Jan 18 2021 05:20 am

> On 17 Jan 21 18:42:46, Rob Swindell said the following to Nick Andre:
>
> RS> Yeah, you're not understanding what I'm saying. BinkD could pretty
> RS> easily s a flag when it receives a signal (whatever signal, it doesn't
> RS> have to be SIGTERM) and then terminate ***when idle**. It sounds like
> RS> you're opposed t the use of a signal for some reasson.
>
> Yeah, I'm not opposed to signals.

Ah, it seemed like you were.

> 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.

https://www.computerhope.com/taskkill.htm

> 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.

No, I think it's more a question of choosing a better design. Polling a file
system for a file's existence is heavy-handed and slow; do it frequent enough
and you'll create an observable impact on the performance of the system.
Handling a signal on the other hand adds no system or application performance
overhead - it's like an interrupt, there's no polling (and definitely no disk
or file system access) involved.

That said, BSO mailers obviously have to poll the file system frequently anyway
since that's just how they work, so adding yet-another-file to check for
wouldn't likely make much difference. It's just another less than ideal design
tacked on top of another less than ideal design.

> 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.
--
digital man

Sling Blade quote #21:
Karl: Coffee makes me nervous when I drink it. Mmm.

--- SBBSecho 3.12-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

From: Dumas Walker (1:2320/105)
To: All
Date: Mon, 18.01.21 14:57
Re: Semaphore
> 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.

I would do it if I knew how.

Mike


* SLMR 2.1a * "Stamp Collection?? Ha-Ha!" - Nelson
--- SBBSecho 3.12-Linux
* Origin: capitolcityonline.net * Telnet/SSH:2022/HTTP (1:2320/105)

From: Rob Swindell (1:103/705)
To: All
Date: Mon, 18.01.21 13:31
Re: Semaphore
Re: Re: Semaphore
By: Rob Swindell to Nick Andre on Mon Jan 18 2021 12:06 pm

> > 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.

Looking at the source code, it appears that BinkD already behaves exactly as
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 if that flag
is set.
--
digital man

Synchronet "Real Fact" #56:
Synchronet Terminal Server introduced SecureShell (SSH) support w/v3.14a
(2006).

--- SBBSecho 3.12-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

ABOUT

This forum contains echomail areas hosted on Nightmare BBS You can browse local echomail areas, italian fidonet areas and a selection of international fidonet areas, reading messages posted by users in Nightmare BBS or even other BBSs all over the world. You can find file areas too (functional to fidonet technology). You can browse echomail areas and download files with no registration, but if you want to write messages in echomail areas, or use fidonet netmail (private messages with fidomet technology), you have to register. Only a minimal set of data is required, functional to echomail and netmail usage (name, password, email); a registration and login with facebook is provided too, to allow easy registration. If you won't follow rules (each echomail areas has its own, regularly posted in the echomail), your account may be suspended;

CONTACT