-
Bug
-
Resolution: Fixed
-
Major
-
None
-
-
docker-plugin version 1.1.9
Testing the latest changes on the trilead-api that fix the use of the timeout on the SSH connection, I've found that the connector used by the docker-plugin passes the connection timeout in the wrong argument, so if the Docker container is not enough fast to start the connection would fail with the following error, notice the *after 0 seconds*
INFO: Can't stop container '7bc1944f6850c40348203db9c23307cde20af1e8d1a57f27c09a06f709e86628' for node 'docker-agent-0004n38ta1rh0' as it does not exist. Oct 13, 2019 7:28:48 PM hudson.slaves.NodeProvisioner lambda$update$6 WARNING: Unexpected exception encountered while provisioning agent Image of jenkins/ssh-slave:jdk11 java.io.IOException: SSH service hadn't started after 0 seconds. at io.jenkins.docker.connector.DockerComputerSSHConnector.createLauncher(DockerComputerSSHConnector.java:261) at io.jenkins.docker.connector.DockerComputerConnector.createLauncher(DockerComputerConnector.java:91) at com.nirima.jenkins.plugins.docker.DockerTemplate.doProvisionNode(DockerTemplate.java:564) at com.nirima.jenkins.plugins.docker.DockerTemplate.provisionNode(DockerTemplate.java:526) at com.nirima.jenkins.plugins.docker.DockerCloud$1.run(DockerCloud.java:364) at jenkins.util.ContextResettingExecutorService$1.run(ContextResettingExecutorService.java:28) at jenkins.security.ImpersonatingExecutorService$1.run(ImpersonatingExecutorService.java:59) at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) at java.base/java.lang.Thread.run(Thread.java:834)
- causes
-
-
- Resolved
-
- links to
[JENKINS-59764] Connection timeout is not honored
pjdarton
added a comment - PR has been merged. Will be FITNR.
Without any information regarding what timeout(s) were set and were expected, the message "after 0 seconds" could be working-as-designed. All it's doing is saying how many seconds (rounded down) things took to fail, so if there's a 100ms timeout then that's all you'd ever see.
i.e. it's not the best error message ever for fast systems :-/
In general, it's best to configure the SSH connector to try multiple times and wait between attempts, and I'd guess that's not what's being done here (otherwise things wouldn't be able to fail so fast).
I've checked the PR and, yes, it looks like the code being changed may well be the source of this problem ... and that'll be discussed in the PR itself.