also sprach Phil Pennock <phil.pennock at globnix.org> [2017-11-15 19:41 +0100]:> So, instead of running no command server side, would a suitable > workaround be to run 'while sleep 1; do echo .; done' as the server > command and discard stdout from ssh on the client side? That way, the > server side should detect the dropped link sooner, leading to sshd exit > and port release.First, we need to debate to death whether it should be while sleep 1; do echo .; done or while echo .; do sleep 1; done ;) Nevermind! What an excellent idea, it's close to client-specified ClientAliveInterval! I can't exactly quantify the effects yet, but a first test (I used `cat /etc/fstab` instead of `echo .` just to fill the pipe a bit faster) shows that the sshd(8) process (a) still sticks around longer than it should but (b) nowhere near as long as it does when using the ssh(1) -N option instead (i.e. run no command on the remote). Thank you! -- @martinkrafft | http://madduck.net/ | http://two.sentenc.es/ #include <signature.h> spamtraps: madduck.bogus at madduck.net -------------- next part -------------- A non-text attachment was scrubbed... Name: digital_signature_gpg.asc Type: application/pgp-signature Size: 1118 bytes Desc: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current) URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20171115/c52cdcdc/attachment-0001.asc>
On 2017-11-15 at 22:44 +0100, martin f krafft wrote:> First, we need to debate to death whether it should be > > while sleep 1; do echo .; done > > or > > while echo .; do sleep 1; done > > ;)Hah. Clearly `while sleep N`, because that way killing the sleep propagates the death out of the loop, making it easier to clean up afterwards. My bikeshed should be blue. I realized afterwards that really, this is too frequent and also that I didn't think through what ssh's default buffering behavior might be without a PTY. The simplest fix is thus to just use `ssh -t` to get line-buffering and have each echo try to pass content to the client. Otherwise, >> dd if=/dev/zero bs=1500 count=1 << is likely to work, but at the cost of a chunk of unnecessary traffic. Really, sacrifice a PTY and let the systems all automatically decide to flush output on each line. -Phil
On 17/11/17 14:27, Phil Pennock wrote:> I realized afterwards that really, this is too frequent and also that I > didn't think through what ssh's default buffering behavior might be > without a PTY.Ssh transfers as soon as possible.? You don't need to worry about line buffering or any such nonsense.? This will work fine: ?? ssh -T host sh -c '"while sleep 1; do echo -n .; done"'