• Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Major Major
    • docker-plugin
    • 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)
      

          [JENKINS-59764] Connection timeout is not honored

          Ivan Fernandez Calvo created issue -
          Ivan Fernandez Calvo made changes -
          Status Original: Open [ 1 ] New: In Progress [ 3 ]
          Ivan Fernandez Calvo made changes -
          Summary Original: The connection timeout is not honored New: Connection timeout is not honored
          Ivan Fernandez Calvo made changes -
          Remote Link New: This issue links to "PR (Web Link)" [ 23828 ]
          Ivan Fernandez Calvo made changes -
          Status Original: In Progress [ 3 ] New: In Review [ 10005 ]
          Ivan Fernandez Calvo made changes -
          Link New: This issue causes JENKINS-53810 [ JENKINS-53810 ]

          pjdarton added a comment -

          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.

          pjdarton added a comment - 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.

          pjdarton added a comment -

          PR has been merged. Will be FITNR.

          pjdarton added a comment - PR has been merged. Will be FITNR.
          pjdarton made changes -
          Resolution New: Fixed [ 1 ]
          Status Original: In Review [ 10005 ] New: Fixed but Unreleased [ 10203 ]

          pjdarton added a comment -

          Code changes went into the release of docker-plugin version 1.1.9

          pjdarton added a comment - Code changes went into the release of docker-plugin version 1.1.9
          pjdarton made changes -
          Released As New: docker-plugin version 1.1.9
          Assignee Original: Ivan Fernandez Calvo [ ifernandezcalvo ]
          Status Original: Fixed but Unreleased [ 10203 ] New: Closed [ 6 ]

            Unassigned Unassigned
            ifernandezcalvo Ivan Fernandez Calvo
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: