18 Nov
2021
18 Nov
'21
5:57 p.m.
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