[HECnet] PyDECnet setup

[Thomas DeBellis]

Yes, I'm aware of that particular practice, yet one hesitates to call it 
a 'standard'.  That being said, I don't think it unreasonable to use 
SIGHUP for something that is never going to have carrier dropped on it.  
So background 'systems' processes would be an obvious candidate.

'Early' Unix to me means before it got ported off the PDP-7.  I started 
using it in about 1978, which I believe was in the first decade of its 
public release from AT&T.  In some ways, it was a significantly 
different beast than what you see, today. However, I didn't start doing 
systems programming on Unix until about 1985 when the plug got pulled on 
36 bits, first Ultrix, then Sun.  This was until about 1988.  Maybe we 
might call that 'middle' Unix?

Being a 'purist' in Unix is really a pointless exercise.  Vendors and 
developers agree on things until they don't agree and when they need 
something, it's anybody's guess as to what might get made into an 
unofficial standard.  You'd be surprised (or not).

I'm not saying it's a bad idea.  I'm saying a Unix 'standard' is 
whatever an unofficial majority thinks it is, which may or may not be 
what others think (say POSIX, for example).  You also see a lot of this 
in the C library.  Timing functions come to mind.

It's a slippery term and what you think is a standard today may not be 
in a decade or two.
> ------------------------------------------------------------------------
> On 11/18/21 10:59 AM, Paul Koning wrote:
>
> Maybe I'm referring to something that doesn't go all the way back to 
> early Unix.  But at least in Linux as far back as I can remember -- 
> certainly back to late last century -- sending SIGHUP to a daemon has 
> been the standard way to say "reload your configuration".  In the 
> startup managers, a reload command applied to a particular daemon's 
> entry acts by sending that signal.
>
> paul
>
>> ------------------------------------------------------------------------
>> On Nov 18, 2021, at 10:50 AM, Thomas DeBellis 
>> <tommytimesharing at gmail.com> wrote:
>>
>> The statement, "Proper Unix fashion", leaves me somewhat uncomfortable.
>>
>> Since I'm ancient, my understanding of SIGHUP is to handle a hangup 
>> detected on the controlling terminal or the death of a controlling 
>> process.  A hangup started out meaning dropping carrier on a modem or 
>> DTR on a hardwired line.  It came to include a broken network 
>> terminal connection.
>>
>> When I think of how to handle a SIGHUP, I usually think of 
>> 'gracefully' stopping a process (I.E., saving the user's work instead 
>> of ditching it) and exiting.  If you don't do that, then something 
>> else has to be used to get rid of you, perhaps a SIGTERM. The problem 
>> is that if somebody wants you gone and you don't go away, you have a 
>> 9 on your hands (SIGKILL). Now that data is gone.
>>
>> If you usurp SIGHUP for such use, then things like NOHUP won't do the 
>> expected thing.  There are certainly reasons to be NOHUP'ed.  In your 
>> superior breaks, you might not want to disappear so somebody has a 
>> chance to attach a debugger to you to try to figure out what happened.
>>
>> I think the better thing to do would be handle a SIGUSR1/SIGUSR2 to 
>> reparse.
>>
>> Of course, "proper" is a very relative term in Unix.  Things change 
>> and sometimes get used for no readily apparent reason, the result 
>> being that an unspoken 'standard' happens.  It is not uncommon.  For 
>> example, Johnny's DECnet bridge does in fact use SIGUSR1 to display 
>> some information.  However, it uses a SIGHUP to do a reparse.  So 
>> maybe that's the best of both worlds...
>>
>> I've never felt strongly enough about the matter to suggest SIGUSR2 
>> for a reparse, but if you want to be a purist, then it probably should.
>>> ------------------------------------------------------------------------
>>> On 11/18/21 9:58 AM, Paul Koning wrote:
>>>
>>>
>>> In proper Unix fashion it could be triggered by a SIGHUP signal
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sonic.net/pipermail/hecnet-list/attachments/20211118/60bd6c46/attachment.htm>