As has been noted previously, when ControlPersist is set, the background process hangs on to stderr until it terminates: https://bugzilla.mindrot.org/show_bug.cgi?id=1330#c1 https://lwn.net/Articles/401651/ This means that any script that uses stderr from an ssh script will hang until the master connection eventually times out. I'm opening this bug because a user noticed that this makes pssh hang: http://code.google.com/p/parallel-ssh/issues/detail?id=67 If the background ssh process were to close stderr, then pssh would not hang.
Closing stderr in the backgrounded process would lose any output from it (usually visiable at loglevel verbose or higher)
(In reply to comment #1) > Closing stderr in the backgrounded process would lose any output from > it (usually visiable at loglevel verbose or higher) But if loglevel is not verbose, there's nothing to lose, right?
not necessarily - e.g. messages sent at loglevel fatal() or error()
If ssh has forked a background daemon, the user can't reasonably expect to see messages on stderr anyway. For example, they might close the terminal in which the original ssh connection was created. Furthermore, such messages might not even be welcome. After all, the user is probably running some other application. Any fatal errors would be relevant to other foreground ssh processes, but not to a terminal window that is no longer running any ssh processes. Might the best long-term solution be to send any logging messages to foreground ssh processes? In any case, I think it's incorrect to send logging messages to a now-unrelated tty. Especially since this can make scripts hang.
Created attachment 2299 [details] daemonize backgrounded mux master with controlpersist please try this patch from tedu: daemon'ize the backgrounded mux master. the new -E options should make the logging more useful in this case.
Comment on attachment 2299 [details] daemonize backgrounded mux master with controlpersist >Index: ssh.c >=================================================================== >RCS file: /cvs/src/usr.bin/ssh/ssh.c,v >retrieving revision 1.378 >diff -u -p -r1.378 ssh.c >--- ssh.c 17 May 2013 00:13:14 -0000 1.378 >+++ ssh.c 6 Jun 2013 01:51:58 -0000 >@@ -947,6 +947,8 @@ control_persist_detach(void) > fatal("%s: fork: %s", __func__, strerror(errno)); > case 0: > /* Child: master process continues mainloop */ >+ if (daemon(1, 0) == -1) >+ fatal("Failed to daemonize control master"); I'd prefer this happen in the block after the switch statement, where the fd cleanup already occurs. Otherwise ok by me
Retarget to openssh-6.4
Retarget 6.3 -> 6.4
nope, it's actually in 6.3: revision 1.381 date: 2013/07/25 00:29:10; author: djm; state: Exp; lines: +2 -1; daemonise backgrounded (ControlPersist'ed) multiplexing master to ensure it is fully detached from its controlling terminal. based on debugging and patch from tedu@ ok dtucker@ "be careful" deraadt@ please reopen if you can reproduce the problem with 6.3 or newer.
(In reply to Darren Tucker from comment #9) > please reopen if you can reproduce the problem with 6.3 or newer. I've been able to reproduce this on 6.2 and 6.6. In those versions (and 6.3 as well), a daemon(1, 1) call is used and stderr is not detached.
I can confirm this bug with $ ssh -V OpenSSH_6.6.1p1 Ubuntu-2ubuntu2, OpenSSL 1.0.1f 6 Jan 2014 $ cat /etc/issue Linux Mint 17.2 Rafaela \n \l
I agree with the other recent comments on this ticket; while the patch discussed on this ticket suggested `daemon(1,0)` (which would have adjusted the file descriptors) the commit as it was landed used `daemon(1,1)` instead, which has no effect on the FDs. It's also not clear why the return code check was omitted.
*** Bug 2000 has been marked as a duplicate of this bug. ***
Created attachment 2810 [details] close ControlPersist stderr when logging to file/syslog or when not in debug mode We want to keep stderr open when in debug mode, so it's a little more complex than that. This patch tries to do the right thing.
Seems to also cause quite some troubles in the use case I've described in bug #2000, which Damien just marked a dup of this one. So people may want to have a look there as well for possibly further information. Can anyone make some predictions whether this issue can be solved? It would even be already helpful, when it would offer a special option that cause the FDs to be closed, just in case there are reasons why you don't want to make that the default. Further, when you have a look at the use case I describe in #2000, it should become obvious that this is done with likely many different versions of OpenSSH (our oldest still in use 5.3, as part of Scientific Linux 6)... do you think it requires just an up to date client (which would be easy for us, as there's one node which opens all the muxes, which anyway runs recent Debian)... or would all servers need to be updated as well?
Created attachment 2811 [details] close ControlPersist stderr when logging to file/syslog or when not in debug mode (v2) Same as last patch, but the logic is a little more readable this way
patch applied - this will be in openssh-7.3 commit d2d6bf864e52af8491a60dd507f85b74361f5da3 Author: djm@openbsd.org <djm@openbsd.org> Date: Fri Apr 29 08:07:53 2016 +0000 upstream commit close ControlPersist background process stderr when not in debug mode or when logging to a file or syslog. bz#1988 ok dtucker Upstream-ID: 4fb726f0fdcb155ad419913cea10dc4afd409d24
Close all resolved bugs after 7.3p1 release
Created attachment 3409 [details] 镜像出错总是报出下载yii asset连接超时
@Damien... have a look at the previous message... weird form of spam (or some image that tries to abuse a security hole)... guess that should be removed and the user banned.