openssh unix dev - Jun 2014 - Improve ControlPersist documentation

Hi,

While testing the ControlPersist option (which is very useful by the way,
thank you), I find out that setting it to 0 has the same behaviour as
setting it to yes, while I would have expected to exit as soon as the last
client exits.

I'd like to make this behaviour clear, I think it should be documentated in
the man page for example like this:

$ cvs diff -u ssh_config.5
Index: ssh_config.5
==================================================================RCS file:
/cvs/openssh/ssh_config.5,v
retrieving revision 1.186
diff -u -r1.186 ssh_config.5
--- ssh_config.5    20 Apr 2014 03:22:46 -0000    1.186
+++ ssh_config.5    12 Jun 2014 22:34:51 -0000
@@ -529,7 +529,10 @@
 .Xr sshd_config 5 ,
 then the backgrounded master connection will automatically terminate
 after it has remained idle (with no client connections) for the
-specified time.
+specified time. If the time is 0, then the backgrounded master connection
+will stay indefinitely (like if set to
+.Dq yes
+).
 .It Cm DynamicForward
 Specifies that a TCP port on the local machine be forwarded
 over the secure channel, and the application

What do you think of that ?

Of course, it would also be a good idea to change the behaviour and exits
as soon as the last client exits. I tried to change the code in this way,
but there is an issue in that the control background process doesn't even
wait for the first client to connect...

Thank in advance,
Best regards
-- 
Lo?c

On Fri, 13 Jun 2014, Lo?c Le Loarer wrote:
> While testing the ControlPersist option (which is very useful 
> by the way, thank you), I find out that setting it to 0 has the 
> same behaviour as setting it to yes, while I would have expected 
> to exit as soon as the last client exits.
I think it should exit immediately, so the current behaviour of 
ControlPersist=0 waiting forever should be considered a bug to be 
fixed in code, not a feature to be added to documentation.
> Of course, it would also be a good idea to change the behaviour 
> and exits as soon as the last client exits. I tried to change 
> the code in this way, but there is an issue in that the control 
> background process doesn't even wait for the first client to 
> connect...
If fixing it properly is too difficult, then waiting for a very 
short time, like 1 second, might be a reasonable compromise.

--apb (Alan Barrett)