The client binary rsh(1) is reacting erroneously on SIGPIPE. This is present since legacy time. The problem is that rsh(1) will, except when called using the switch "-n", be using a forked child process. When the parent process receives a signal SIGPIPE this parent process will immediately abort, and will never send a shutdown signal to the child process. This situation typically arises when rsh(1) is part of a command line pipeline, where one member fails. Fix: The problem is that the legacy code never installs a signal handler for SIGPIPE in the function talk(), but only later kills the client process in main(). From the fact that the default handler for SIGPIPE is process abortion, the whole problem arises. Since I personally resolved this issue in a GNU project based on BSD legacy code for rsh(1), I regretfully cannot produce a patch for the fear of poluting your code base away from its present license, but the above mechanism is the culprit of this annoying issue. How-To-Repeat: The use cases $ rsh localhost cat /etc/motd | false $ rsh localhost date | true will leave a child process still running, and will in turn keep the server process running indefinitely and will also steal stdin from the login session.
For bugs matching the following criteria: Status: In Progress Changed: (is less than) 2014-06-01 Reset to default assignee and clear in-progress tags. Mail being skipped