Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!wuarchive!udel!haven!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn)
Newsgroups: comp.unix.wizards
Subject: Re: RSH (remote shell) - must all children die before remote part exits?
Message-ID: <11814@smoke.BRL.MIL>
Date: 14 Dec 89 08:38:38 GMT
References: <1035@anasaz.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 26

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? That seems to be the way it
>works on our Pyramid MIS machine and a couple of 386/IX boxes. It
>doesn't matter if I do a nohup and/or run things in background; server
>processes on both ends stick around until everything on the remote
>side terminates.

I frankly didn't understand what you were asking, but here is how
4.3BSD "rsh" functions on the remote end:

On the remote system, the rshd process that inetd starts up to service
the connection forks into two processes.  The child is overlaid by the
command that you specified when invoking "rsh". The child's stdin and
stdout are connected to one socket, and the child's stderr is piped
to the rshd parent, which merely routes stderr and signal information
through a second socket.

If the overlaid rshd child terminates, the rshd parent will notice
this (read on a broken pipe used for child stderr) and also go away,
severing the second socket connection.  (The first was severed when
the child terminated.)

By the way, if you don't specify a command then 4.3BSD "rsh" invokes
"rlogin" instead, which uses a different protocol.