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