You can use a program that prints out information about open file descriptors
using fstat, run that from bash so it inherits the open fd, and try to
track down what kind of fd is is from that (socket, file, etc.).  It's
possible that it's a file descriptor left open by the YP library functions.

Message describing the bug:

This is a bug alright, but it's a bug with rshd that's not fixed until
4.3-reno.

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.

I don't know how to solve this cleanly in bash.  Doing a blanket close of
all open file descriptors < 2, < 20 is a no-no, especially when we're not
interactive.  csh `works' because it does the blanket close on startup, but
csh can get away with doing that because it doesn't let you manipulate
arbitrary file descriptors.

Chet

--
``The lyf so short, the craft so long to lerne.'' - Chaucer

Chet Ramey, Case Western Reserve University     Internet: c...@po.CWRU.Edu