similar to: [Bug 1812] New: ControlPersist causes defunct/zombie processes

Hi I'm trying to wrap ssh in an application using glib. For now, I'm launching the ssh client in master mode and want it to detach, keeping the control socket around. I figured I could do that using the -f flag and the usual Control* options to force ssh to daemonize (ideally without executing any command), but it turns out that glib doesn't recognize the daemonized process as

Hi. Perhaps you can help me with this: What I do is using Nagios (actually Icinga) and having checks on remote hosts executed via ssh. In order to dramatically speed checks up (from about 0,300 ms to 0,010 ms) I use ControlMaster = auto, which also makes the mux process spawned on the first check. As checks are typically sequentially scheduled I want the mux process to persist but it should

https://bugzilla.mindrot.org/show_bug.cgi?id=2000 Damien Miller <djm at mindrot.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |DUPLICATE Status|REOPENED |RESOLVED --- Comment #9 from Damien Miller <djm at

https://bugzilla.mindrot.org/show_bug.cgi?id=2000 --- Comment #10 from Christoph Anton Mitterer <calestyo at scientia.net> --- Hmm AFAIU, when not using ControlPersist, that would simply mean that if the last session is closed, the mux closes either, right? This is however undesirable as well for the above use-case: First, considers hosts where only one check runs (i.e. executed via

https://bugzilla.mindrot.org/show_bug.cgi?id=2000 Damien Miller <djm at mindrot.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |djm at mindrot.org --- Comment #7 from Damien Miller <djm at mindrot.org> --- If ControlPersist's stderr

https://bugzilla.mindrot.org/show_bug.cgi?id=2000 Damien Miller <djm at mindrot.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #5 from Damien Miller <djm at mindrot.org> --- Set all RESOLVED bugs to CLOSED with release

https://bugzilla.mindrot.org/show_bug.cgi?id=2000 Christoph Anton Mitterer <calestyo at scientia.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|INVALID |--- Status|CLOSED |REOPENED --- Comment #6 from Christoph Anton

https://bugzilla.mindrot.org/show_bug.cgi?id=2000 --- Comment #8 from Christoph Anton Mitterer <calestyo at scientia.net> --- Uhm? Well I thought that was obvious... using SSH to remotely execute checks seems desirable because it's a) the protocol meant for doing this b) secure (unlike e.g. NRPE). But without control channel muxing, it's much slower than e.g. NRPE, as all the

https://bugzilla.mindrot.org/show_bug.cgi?id=2000 Bug #: 2000 Summary: when using ssh with ControlMaster/ControlPersist, one may get zombie processes Classification: Unclassified Product: Portable OpenSSH Version: 5.9p1 Platform: All OS/Version: All Status: NEW Severity: major

https://bugzilla.mindrot.org/show_bug.cgi?id=3220 Bug ID: 3220 Summary: Possible bug if ControlMaster + ControlPersist and `-t` Product: Portable OpenSSH Version: 8.4p1 Hardware: Other OS: Linux Status: NEW Severity: enhancement Priority: P5 Component: ssh

Hi all, When a client requests dynamic remote forwarding with -R it delays forking into the background. In ssh.c we see if (options.fork_after_authentication) { if (options.exit_on_forward_failure && options.num_remote_forwards > 0) { debug("deferring postauth fork until remote forward " "confirmation received");

On Fri, 9 Jun 2023, Chris Rapier wrote: > Hi all, > > When a client requests dynamic remote forwarding with -R it delays forking > into the background. In ssh.c we see > > if (options.fork_after_authentication) { > if (options.exit_on_forward_failure && > options.num_remote_forwards > 0) { > debug("deferring postauth fork until

Hey folks, I am trying to get an E65 to connect to asterisk, and I would really appreciate a second set of eyes. The SIP dialog completes fine, but the phone subsequently says "Registration failed". I am in a network that has what seems to be a SIP-capable NAT gateway, but the asterisk is configured nat=yes anyway. Using a softphone (twinkle), I can connect just fine, SIP and RTP work.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello, There seems to be just a bit to do with the latest openssh (5.8p1) and ControlPersist. I encountered two problems: 1. When I use ControlPersist in combination with ProxyCommand to reach a other host over that proxy I get the following message: Bad packet length 1397966893. Disconnecting: Paket corrupt When I fist ssh to

Good afternoon! I've been looking for a way to avoid having to keep my "master" ssh session open while I have others open. This is particularly a pain when my "master" is an scp connection. After searching the archives, I came up with this thread "ControlPersist and multiple X11 forwardings." However, I can't find anything saying that it was

https://bugzilla.mindrot.org/show_bug.cgi?id=2394 Bug ID: 2394 Summary: Provide a global configuration option to disable ControlPersist Product: Portable OpenSSH Version: 6.8p1 Hardware: Other OS: Linux Status: NEW Severity: enhancement Priority: P5 Component: ssh

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:

https://bugzilla.mindrot.org/show_bug.cgi?id=1988 Darren Tucker <dtucker at zip.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dtucker at zip.com.au Blocks| |2076 -- You are receiving this mail

https://bugzilla.mindrot.org/show_bug.cgi?id=1943 Bug #: 1943 Summary: [PATCH] ssh -W opens two connections when ControlPersist is enabled. Classification: Unclassified Product: Portable OpenSSH Version: 5.9p1 Platform: All OS/Version: All Status: NEW Severity: normal Priority:

Hello, We are running Asterisk-1.0.12 in a CentOS 4-4.2 system, kernel 2.6.9-42.0.3.ELsmp. We have some custom AGI, and when we launch Asterisk the system works fine. But **after some time**, each AGI execution generates a zombie <defunct> process. We believe that it's not a problem in the AGI code, because Asterisk+AGI is working fine in the first "n" minutes/hours. This