https://bugzilla.mindrot.org/show_bug.cgi?id=1330
--- Comment #19 from Martin Ling <[email protected]> --- (In reply to comment #17) > > That seems more confusing to me, and I don't see what the advantage > would be. As far as I can tell, everything your system of 3 > variables could accomplish can also be accomplished with the existing > ControlPersist = yes/no/timespec option. I wasn't really intending to offer more possibilities, rather just avoiding overloading one option with multiple meanings. As you point out, having 'no' and '0' mean different things is confusing. Maybe there's a good two-option compromise. Do we agree on the use cases that need to be supported? I think they are: 1. master session held open till slaves exit (original behaviour) 2. master backgrounded on first session exit, closes with last slave. 3. master backgrounded on first session exit, closes after timeout. 4. master backgrounded on first session exit, never closes. -- Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug. You are watching someone on the CC list of the bug. _______________________________________________ openssh-bugs mailing list [email protected] https://lists.mindrot.org/mailman/listinfo/openssh-bugs
