descriptor 6

descriptor 6

[Scott Schwartz]

Hi all,


When I do this

	rsh roke -n 'sleep 100 >/dev/null >[2=1] &'

the rsh doesn't return immediately, as I would have expected.
It looks like file descriptor 6 is open on the other end, 
preventing rshd from exiting.  Is this an rc-ism?  Is there a
preferred idiom for closing all unwanted descriptors?

Re: descriptor 6

[Chris Siebenmann]

 Various versions of rsh on various systems (probably with various
options, too) leave all sorts of file descriptors open. The best
way I've found of dealing with this so far is to figure out which
descriptors are being left open and then close them manually.
I suppose there's a great future for a 'clean' command that fixes
this sort of thing.

	- cks

Re: descriptor 6

[Chet Ramey]

> When I do this
> 
> 	rsh roke -n 'sleep 100 >/dev/null >[2=1] &'
> 
> the rsh doesn't return immediately, as I would have expected.
> It looks like file descriptor 6 is open on the other end, 
> preventing rshd from exiting.  Is this an rc-ism?  Is there a
> preferred idiom for closing all unwanted descriptors?

This is a bug in rshd, fixed in 4.3-reno but present in all earlier
versions.

Here's an excerpt from a message I sent to a few people describing
the bug:

rshd sets up a pipe (int pv[2]; if you have the source to the tahoe rshd)
to the process it executes and uses it to manage error and control output
from over the net.  In the child process, it does a dup2(pv[1], 2), but
never calls close(pv[1]).  Adding that code to the 4.3-tahoe rshd makes it
(and the Xemacs script) work right. 

--
``Teach them politics and war so their sons may study medicine and mathematics
in order to give their children a right to study painting, poetry, music, and
architecture.''
Chet Ramey, CWRU  Inet: chet@po.CWRU.Edu   NeXT Mail: chet@macbeth.INS.CWRU.Edu