[HECnet] PyDECnet setup

They do it _today_. I can't remember what I did in 1986, honest.? Of course I've changed /etc/inetd.conf when I put up new services.? And I can't for the life of me remember what I did to poke a re-parse. If it was a SIGHUP, then I probably thought that odd.? Now I'm dissatisfied with the term Unix 'standards' because they are until they aren't, also depending on what implementation you happen to find yourself trying to execute on.? And if it needed to change, why exactly did the old interface need to get ditched, really?? Now I have a bunch of scripts to rewrite.? For what? I think you can get burnt whether it's a bunch of academics eternally discussing purity in committees or a couple of kids just picking something. > ------------------------------------------------------------------------ > On 11/18/21 12:04 PM, Dave McGuire wrote: > > ? Both Ultrix and SunOS do this in most of their major subsystems. > Surely you've made changes to /etc/inetd.conf. > > ?????????? -Dave >> ------------------------------------------------------------------------ >> On 11/18/21 12:02 PM, Thomas DeBellis wrote: >> >> Well, I don't remember Ultrix or SunOS doing this when I was one of >> Columbia's Unix Systems Programmers.? However, that might mean >> exactly nothing more than I don't remember and that they did do it. >> I don't remember it in any daemon that I developed. Of course, I can >> barely remember any daemon I developed... >> >> My dissatisfaction is not with the practice itself so much as what >> winds up being called a standard and who says it is.? Until somebody >> says different... >> >> >>> ------------------------------------------------------------------------ >>> On 11/18/21 11:43 AM, Dave McGuire wrote: >>> >>> ? Tom, you're describing "proper 1970s UNIX fashion".? A SIGHUP to >>> reload/reconfigure a running process has been standard since the >>> mid/late 1980s, perhaps even earlier. >>> >>> ?????????? -Dave >>>> ------------------------------------------------------------------------ >>>> On 11/18/21 10:50 AM, Thomas DeBellis 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 >>> >>> > >