https://bugzilla.mindrot.org/show_bug.cgi?id=3743
--- Comment #3 from Shish <[email protected]> --- Reading the docs and the source code for a few more hours, I am actually more confused than I was to start with... but one bit of clarity is that my confusion comes from detaching, not from forking per-se. Currently implemented behaviour seems to be: | ControlPersist=no | ControlPersist=yes ------------------------+-------------------+------------------------- ssh host sleep 10 | attached | attached ssh -f host sleep 10 | detached | detached ssh -N host | attached | detached (??) ssh -f -N host | detached | detached Rows 1, 2 and 4 make sense to me. Row 3 feels weird, like the detachment was a side-effect rather than intentional behaviour? The code comments seem to imply that the persistent master forks off into the background and expects a new mux-client to come along and run in the foreground (by default) or background (with -f) -- but in the case of -N, the new mux-client doesn't come along (or does it come along and exit immediately? I'm a bit lost here), and we're left with the master running in the background and the foreground becomes detached by default rather than by choice. -- You are receiving this mail because: You are watching someone on the CC list of the bug. You are watching the assignee of the bug. _______________________________________________ openssh-bugs mailing list [email protected] https://lists.mindrot.org/mailman/listinfo/openssh-bugs
