Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!cs.utexas.edu!asuvax!anasaz!duane
From: duane@anasaz.UUCP (Duane Morse)
Newsgroups: comp.unix.wizards
Subject: RSH (remote shell) and waiting on program termination - SUMMARY
Summary: Summary - cavaet emptor
Message-ID: <1051@anasaz.UUCP>
Date: 18 Dec 89 15:25:43 GMT
References: <1035@anasaz.UUCP>
Organization: Anasazi Inc., Phoenix AZ
Lines: 30

In article <1035@anasaz.UUCP>, duane@anasaz.UUCP (Duane Morse) writes:
> Is it a feature of rsh that the process started on the remote end
> and all of its children terminate before the remote shell (and its
> partner on the local side) terminate?

Thanks for the e-mail and the Usenet postings. In summary, most people
seem to think that redirecting stdin, stdout, and stderr to /dev/null on the
target host should be sufficient to allow the rsh on the local host to terminate
without waiting for the program(s) on the target to terminate. That isn't
the case on the two 5.3 machines we have.

In particular, between one 386/ix machine and another 386/ix machine,
it appears necessary to run both sides with I/O redirected to /dev/null.
Further, one must run the target side 'nohup'. Example:
rsh target 'nohup prog </dev/null >/dev/null 2>&1 &' </dev/null >/dev/null 2>&1

Between two Pyramid MIS machines, even this extreme doesn't work; the
local rsh just plan hangs around until target is done. This is a Pyramid
peculiarity; it occurs even if the host is a 386/ix machine. The
other arrangement works if the host is the Pyramid and the target is a
386/ix machine. [Note: on the Pyramid, this is the AT&T universe I'm
talking about.]

Hence, some combination of 'nohup', redirecting I/O to /dev/null, and
running the target program(s) in background should work, but the combination
that works for your machines may vary.
-- 

Duane Morse	e-mail: duane@anasaz (or ... asuvax!anasaz!duane)
(602) 861-7609