brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Heneveld (JIRA)" <>
Subject [jira] [Commented] (BROOKLYN-361) Brooklyn will block on initial ssh attempt indefinitely
Date Wed, 14 Dec 2016 17:30:58 GMT


Alex Heneveld commented on BROOKLYN-361:

Could we configure SSH so that the first connection waits 15s for a response and if it times
out it tries again with a longer (2m) timeout?

Reason is that IRL I've encountered two issues:

1) some servers accept socket connection on startup, before SSH is actually ready to handle,
and wait indefinitely; a shorter timeout of for the first attempt will catch these
2) some servers esp when they can't reverse-DNS-lookup IP's, block for 1m+ trying to do so
before proceeding to authorise connections

Both are external misconfigurations but they happen often enough and we can be robust in the
face of them.

> Brooklyn will block on initial ssh attempt indefinitely
> -------------------------------------------------------
>                 Key: BROOKLYN-361
>                 URL:
>             Project: Brooklyn
>          Issue Type: Bug
>            Reporter: Svetoslav Neykov
> Had a case where the initial ssh attempt  would hang at 
> {noformat}
> Opening ssh connection
> Task[ssh: initializing on-box base dir ./brooklyn-managed-processes]@PYxsD6KS
> Submitted by SoftlyPresent[value=Task[pre-start]@yQTQ08Py]
> In progress (RUNNABLE)
> At: net.schmizz.sshj.transport.TransportImpl.init(
>     net.schmizz.sshj.SSHClient.onConnect(
>     net.schmizz.sshj.SocketClient.connect(
>     net.schmizz.sshj.SocketClient.connect(
>     org.apache.brooklyn.util.core.internal.ssh.sshj.SshjClientConnection.create(
>     org.apache.brooklyn.util.core.internal.ssh.sshj.SshjClientConnection.create(
>     org.apache.brooklyn.util.core.internal.ssh.sshj.SshjTool.acquire(
>     org.apache.brooklyn.util.core.internal.ssh.sshj.SshjTool.acquire(
>     org.apache.brooklyn.util.core.internal.ssh.sshj.SshjTool.connect(
>     org.apache.brooklyn.location.ssh.SshMachineLocation.connectSsh(
>     org.apache.brooklyn.location.ssh.SshMachineLocation$10.get(
>     org.apache.brooklyn.location.ssh.SshMachineLocation$10.get(
>     org.apache.brooklyn.util.pool.BasicPool.leaseObject(
>     org.apache.brooklyn.util.pool.BasicPool.exec(
>     org.apache.brooklyn.location.ssh.SshMachineLocation.execSsh(
>     org.apache.brooklyn.location.ssh.SshMachineLocation$13.execWithTool(
>     org.apache.brooklyn.util.core.task.system.internal.ExecWithLoggingHelpers.execWithLogging(
>     org.apache.brooklyn.util.core.task.system.internal.ExecWithLoggingHelpers.execScript(
>     org.apache.brooklyn.location.ssh.SshMachineLocation.execScript(
>     org.apache.brooklyn.util.core.task.ssh.internal.AbstractSshExecTaskFactory$
>     org.apache.brooklyn.util.core.task.system.ProcessTaskWrapper$
>     org.apache.brooklyn.util.core.task.BasicExecutionManager$
> {noformat}
> The reason in this case is that the connection goes through a proxy and it will accept
a connection and keep it open indefinitely if there's no upstream host to forward to.
> Another case of the same problem at
> Should time out if ssh handshake doesn't complete in a reasonable time.

This message was sent by Atlassian JIRA

View raw message