| Summary: | Sporadically need to press <ENTER> for multiplexed connection to finish | ||
|---|---|---|---|
| Product: | Portable OpenSSH | Reporter: | Omar Estrada <omar.estrada> |
| Component: | ssh | Assignee: | Assigned to nobody <unassigned-bugs> |
| Status: | CLOSED WORKSFORME | ||
| Severity: | minor | CC: | djm, dtucker |
| Priority: | P5 | ||
| Version: | 7.3p1 | ||
| Hardware: | amd64 | ||
| OS: | Linux | ||
I can't reproduce this on either of: - Fedora 24 (i686, kernel 4.7.3-200.fc24.i686+PAE) - Ubuntu 16.04.1 (x86_64, kernel 4.4.0-43-generic) Could you describe your system some more (eg distro, kernel)? What shell are you using? 9 months with no followup == no bug Close all resolved bugs after release of OpenSSH 7.7. |
Sometimes, when issuing a remote command via a multiplexed connection, it doesn't finish until I hit <ENTER>. Most of the times it terminates normally. This occurs approximately 1 out of 10 times. This affects the usage of multiplexed connections in scripts. Adding -vvv to the "slave" connection shows: debug3: mux_client_request_session: entering debug3: mux_client_request_alive: entering debug3: mux_client_request_alive: done pid = 5485 debug3: mux_client_request_session: session request sent debug1: mux_client_request_session: master session id: 3 <Have to hit ENTER here> debug3: mux_client_read_packet: read header failed: Broken pipe debug2: Received exit status from master 0 I checked out the code (commit 775f8a23f2353f5869003c57a213d14b28e0736e) and, after adding some additional log messages to mux.c, I notice the flow was blocking in mux_client_read(), in the call to poll(): 1428 static int 1429 mux_client_read(int fd, Buffer *b, u_int need) 1430 { ... 1450 case EAGAIN: 1451 (void)poll(&pfd, 1, -1); <<<<<<<<<<< 1452 /* FALLTHROUGH */ Steps to reproduce: 1. In a terminal, issue: ssh -M -S $TMPDIR/master <host> 2. In another terminal, issue: for i in `seq 30`; do ssh -vvv -o ControlPath=$TMPDIR/master <host> ls; done Expected behavior: the command finishes running without user interaction. Actual behavior: approx. 1 out of 10 times it's necessary to press <ENTER> (no other key works) to continue executing the command. WORKAROUND: Notice that redirecting STDIN to /dev/null works around the problem (e.g., for i in `seq 30`; do ssh -vvv -o ControlPath=$TMPDIR/master <host> ls < /dev/null; done