Hello. When I attempt to run ssh with the -f (fork in background) flag or from a cron job I get the error: "select: No such device or address." It appears to be a problem with ssh communicating with the TTY. The OS is NCR MP-RAS SVR4 version 3.2. Nothing fancy in the compile (./configure / make). I was able to reproduce the problem in both 3.8p1 and the current release. I will attach the output with the error to the bug report. The test program I used was a simple shell with the command "ssh system_name ls -l" that was scheduled as a cron job.
Created attachment 708 [details] Output in verbose mode when the error occurrs
Would be nice to see a "sshd -ddd" from remote side.. Also is the remote server a MP-RAS? Redhat? what is it? - Ben
Created attachment 711 [details] sshd -ddd output
I've had the problem occur on MP-RAS and Redhat remote servers. As a side note it always returns the message "select: No such device or address" but will sometimes complete the remote command. The majority of the time however the remote command doesn't appear to run. -Steve
Does ssh it give that select error when run from an interactive shell? If you redirect ssh's stdin/stdout in the cron job, does it work? eg ssh -f yourserver command </dev/null >/dev/null 2>/dev/null
Running from an interactive shell (without the -f option) works fine. It only errors when running from a crontab or using the -f option interactivly. Redirecting stdin/stdout/stderr still will generate the "select" error. I ran the following which redirected everything and still got the error: ssh -f myserver "ls </dev/null >/dev/null 2>/dev/null" >/tmp/test.out 2>&1 </dev/null In the test.out file I had the "select" error. I also ran variations of the above command. All of them returned the select error.
Does redirecting the output to /dev/null in the interactive shell cause the select errors? Also, does "lsof" work on that platform? If so, comparing the output from lsof for an interactive login and the cron job may prove enlightening...
I do not have the lsof program on this platform. Running the command in an interactive shell and redirecting to >/dev/null DOES cause the select error to happen. The command: ssh myserver ls >/dev/null will generate a select error.
Also try the patch in bug #830, and if that's it please close this bug as a duplicate of #830.
I applied the patch from 830 and it partially fixed the problem. Interactively the -f option now works, as long as you don't redirect the ssh output to /dev/null (prior to the patch -f failed every time). I still get the select() error when I redirect stdout to /dev/null without the - f option. If the output is redirected to a file I don't get a select() error. It only happens when redirected to /dev/null. I did find that if the remote command that is executed doesn't return any output the select() error will not occur.
Could you please try with a recent version of OpenSSH? There have been quite a number of channels bugs fixed since this bug was last updated.
I'll close this bug for inactivity. If you are able to reproduce it with a more recent version then feel free to reopen it.
Close all resolved bugs after 7.3p1 release