[HECnet] PyDECnet setup

[Johnny Billquist]

The use of SIGHUP for different things in different ways goes way back.

As you describe, Thomas, SIGHUP is essentially telling user programs 
that the modem line was hung up, and program should terminate gracefully.

However, for pretty much as long, the init process have also responded 
to SIGHUP by reloading /etc/ttys, which in turn enables or disables 
individual terminal lines.

The idea of using SIGHUP for reloading configs in daemons comes from 
this use in init, and obviously in init it was pretty clear that a 
normal usage SIGHUP would never happen anyway.

And it is in general true for daemons. They don't have a terminal to 
begin with, so SIGHUP in the normal sense will never happen. So the 
signal can be used for something else. In the old days SIGUSRx didn't 
exist. So you had to make use of what signals there were, and SIGHUP 
sortof made sense from that point of view.

Nowadays? Unix have lost its soul anyway... It's all Linux, and the kids 
are indeed changing things just for the sake of changing things...

   Johnny

On 2021-11-18 17:57, Thomas DeBellis wrote:
> 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
>>

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt at softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol