response 25 of 57:

Apr 21 12:46 UTC 1995

Hm.  Then I guess I misunderstood the last paragraph of response #19.

response 27 of 57:

Apr 22 18:09 UTC 1995

You said "it depends on the root who is investigating at the time".
It does not. Nohups are zapped automatically and without prejudice.
Neither you nor anyone else is singled out for better or worse.

response 29 of 57:

Apr 23 05:58 UTC 1995

They're jobs run in the background, they're zapped if the person has
logged off because they can take up lots of CPU to the detriment of
interactive users, and it was felt this was not a reasonable use of the
system, and, no, it's done automatically not manually.

response 31 of 57:

Apr 23 12:56 UTC 1995

To re-state what Marcus said: "nohup" is the name of a command you
can use to say "run this other command, and leave it going even after
I log off".  I think "nohup" is short for "no hang-up (the phone)".

response 33 of 57:

Apr 24 04:20 UTC 1995

nohup is a program that starts your program as a subprocess.
It handles the C signal HUP (the hang-up signal) but does nothing with it.
If it were not handled, it would kill your program.

nohup is very handy on most unix systems, but has been deemed an inappropriate
use on Grex. The main function of the idle zapper is to catch buggy programs
that don't terminate conveniently sometimes. It zaps nohuppers as a byproduct.

response 35 of 57:

Apr 24 12:37 UTC 1995

   Greg wrote the script more than a year ago, and we talked about
it in either an item in coop or agora.

   The reason for it was simple: we were running out of pty's, rather
often.  If a person on a pty left something in the backgound, then
that pty was withheld from the pool of available pty's, until that
process finished.  Over time, we saw "holes" in the ttyuse log, where
all the lower numbered pty's (ttyp0, p1, ...) had less use than the
q or r series.

   So because of that, and the fact that people were intentionally
leaving things to run in the background, we decided to disallow them.

response 37 of 57:

Apr 25 02:03 UTC 1995

(Don't forget tin.)
These *very* often got left by a user who waited (say) half an hour or more
for trn to come up, & then gave up and disconnected.  News was *slow*,
& slows everything else down under those circumstances.

response 39 of 57:

Apr 25 05:51 UTC 1995

(don't forget nethack)
Yes, these programs have bugs that cause this bad behavior, but there were
quite a number of such buggy programs. If implemented right, a program
should not suck cpu when it gets disconnected, no matter how rudely.

response 41 of 57:

Apr 25 12:09 UTC 1995

hmmm, could nohup be a membership perk? I fully understand/understood
the reasons for zapping nohups, I was only commmenting that the
automated process was new to me. And, this discussion reinforces
some of the decisions made in the past, and bring +everyone+ up
to date. Thankxx steve.

response 43 of 57:

Apr 25 16:20 UTC 1995

  What types of things do people do that they run in the background
for more than a half hour under a normal load?  Seems like it must
involve a *lot* of disk access or number crunching.

response 45 of 57:

Apr 26 09:08 UTC 1995

I've been away for awhile. I'll respond to a number of things:
1.) We do not have an "idle zapper" program on grex. The current run state
    of a process is not examined. What we have is an "orphan process zapper".
    Every 15 minutes, this program wakes up and looks for any running,
    non-root, process whose owner is no longer logged in on the tty/pty
    that the process was started on.
2.) This program was written not just to kill programs that were intentionally
    left running, but to kill a number of programs(lynx, nethack, trn, tin)
    that had bugs in their character input routines. This bugged caused
    these programs to consume *enormous* amounts of CPU under the right
    conditions. Unfortuneatly, it would be impossible to allow certain
    users to leave nohup programs running, because there would be no good way
    to distinguish between a good background program and one that had gone
    flaky. This just isn't an option.
3.) *Alot* of modern modems, in fact almost all of them, have inactivity
    timers. Most have had them for *years*.
4.) The modem is the best place to do this. Certain programs can decieve
    UNIX into believing that a tty is idle when it isn't, but the modem
    will *always* know. Unfortunately, there is no way to conditionalize
    this. The modem knows nothing about UNIX, and users, and processes. It
    just sees streams of characters. It could be hooked to a Mac for all
    it knows.
5.) Just to be clear: We are only talking about hanging up the 9600 baud
    lines, not the 2400 baud lines, and we're only talking about hanging
    up lines that have been *IDLE* for 20 minutes, not setting a hard time
    limit. Actually, I though I was being overly *generous* when I set the
    modems for 20 minutes. There are only 4 high speed dialins. They are
    a limited resource. There is no good reason for somebody to sit idle
    on one for 10 minutes, let alone 20 minutes. If you want to run something
    that takes longer that 20 minutes to run and doesn't produce *any*
    output, what the hell are you doing on a high speed line??? Please, log
    off and reconnect to one of the 2400 baud lines for this kind of work,
    don't tie up a high speed line for 20 minutes for a job that *DOESN'T
    PRODUCE ANY OUTPUT*!!!!

response 47 of 57:

Apr 26 12:27 UTC 1995

(Yes, I know you were referring to the high-speed lines only, but I
couldn't resist...)

response 49 of 57:

Apr 27 10:58 UTC 1995

I could also modify the orphan killer to bypass certain user ID's. This 
would allow staff to leave things running. Unfortuneately, it would also
prevent the program from killing an errant lynx,tin,trn,nethack,etc that
went into brain-damaged-mode after a staffer logged off.

There may be other solutions, let me think on this one.