he in.rexecd doesn't behave as the man page indicates. The man page says that the server first reads in a number up to a NUL and then connects back to the client on that socket for the error stream. I ran in.rexecd under strace and verified that in fact after the server reads in the port number it sits there trying to read more data rather than connecting the socket. Here's the relevant excerpt from the system trace: dup2(0, 0) = 0 dup2(0, 1) = 1 dup2(0, 2) = 2 alarm(60) = 0 read(0, "6", 1) = 1 read(0, "5", 1) = 1 read(0, "4", 1) = 1 read(0, "7", 1) = 1 read(0, "1", 1) = 1 read(0, "\0", 1) = 1 alarm(0) = 60 read(0, 0xbffddbaf, 1) = ? ERESTARTSYS (To be restarted) --- SIGTERM (Terminated) --- +++ killed by SIGTERM +++ The SIGTERM was from me killing the process. From the alarm (0) you can see that the process is just going to sit there trying to read. As I said, the man page indicates that the server is supposed to immediately create a connection back to the client at the port specified. Because of this, rexec doesn't work. ‰
*** This bug has been marked as a duplicate of 1696 ***