Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-38705

Docker JNLP launcher does not appear to honor Connect Timeout setting

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Minor Minor
    • docker-plugin
    • None
    • Jenkins: 2.23
      Docker Plugin: 0.16.2
      Docker: 1.11.1 (+swarm)

      I get several orphaned Docker containers per day with the following endless output in the logs:

      + cat
      + chmod +x /tmp/init.sh
      + exec /tmp/init.sh
      + export CONFIG=/tmp/config.sh
      + CONFIG=/tmp/config.sh
      + '[' '!' -f /tmp/config.sh ']'
      + echo 'No config, sleeping for 1 second'
      No config, sleeping for 1 second
      + sleep 1
      + '[' '!' -f /tmp/config.sh ']'
      + echo 'No config, sleeping for 1 second'
      No config, sleeping for 1 second
      + sleep 1
      + '[' '!' -f /tmp/config.sh ']'
      + echo 'No config, sleeping for 1 second'
      
      

      (... continued forever)

      Looking at /tmp/init.sh on the looping container I see this at the top:

      #!/usr/bin/env bash
      
      set -uxe
      
      export CONFIG="/tmp/config.sh"
      while [ ! -f "$CONFIG" ]; do
          echo "No config, sleeping for 1 second"
          sleep 1
      done
      
      echo "Found config file"
      source "$CONFIG"
      
      

      If for whatever reason a config file is not copied to the container, this is what I would expect to happen. What does the Connection Timeout setting in the Jenkins cloud configuration do then? My opinion is that regardless of whether that setting is applicable here (or even to JNLP option at all), this loop should not go on forever but should have a sane default maximum iteration limit.

      Happy to provide a PR if needed, but want to get feedback first.

          [JENKINS-38705] Docker JNLP launcher does not appear to honor Connect Timeout setting

          pjdarton added a comment -

          The docker-plugin now has a "reap orphaned containers" background process that'll quietly dispose of any containers that've been left after a failed connection.  That went in with version 1.1.5.

          That said, I don't think the code you're referring to is part of the docker-plugin - the docker-plugin uses containers but doesn't dictate their contents (aside from when we're doing an SSH connection to a container - then it can push ssh keys onto the container - but no code like this).

          e.g. When the docker-plugin is using JNLP, it provides the newly-created container all the information the container will need to connect back to Jenkins (as arguments to the container's entrypoint) but the docker-plugin does not have anything to do with any /tmp/config.sh file.

          pjdarton added a comment - The docker-plugin now has a "reap orphaned containers" background process that'll quietly dispose of any containers that've been left after a failed connection.  That went in with version 1.1.5. That said, I don't think the code you're referring to is part of the docker-plugin - the docker-plugin uses containers but doesn't dictate their contents (aside from when we're doing an SSH connection to a container - then it can push ssh keys onto the container - but no code like this). e.g. When the docker-plugin is using JNLP, it provides the newly-created container all the information the container will need to connect back to Jenkins (as arguments to the container's entrypoint) but the docker-plugin does not have anything to do with any /tmp/config.sh file.

            pjdarton pjdarton
            akom Alexander Komarov
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: