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

cat command in docker agents not detected correctly

    Details

    • Type: Improvement
    • Status: Reopened (View Workflow)
    • Priority: Minor
    • Resolution: Unresolved
    • Component/s: docker-workflow-plugin
    • Labels:
      None
    • Environment:
      Jenkins 2.104 on Docker 17.10.0-ce on CentOS 7.4.1708 (Kernel 3.10.0-693.2.2.el7.x86_64)
    • Similar Issues:

      Description

      When using a declarative Jenkins pipeline with a stage that uses a Docker agent, I get a confusing error message in the Jenkins log:

      $ docker top 08e1c013e07083492ad0f03285f1a7d30063fb15e0cf39be7b55af6d1a03c829
      ERROR: The container started but didn't run the expected command. Please double check your ENTRYPOINT does execute the command passed as docker run argument. See https://docs.docker.com/engine/userguide/eng-image/dockerfile_best-practices/#entrypoint for entrypoint best practices.
      

      The build continues normally and the cat command is actually running inside the container, so everything is fine except that the error message occurs although it shouldn't.

      Comparing the code in listProcess in https://github.com/jenkinsci/docker-workflow-plugin/blob/master/src/main/java/org/jenkinsci/plugins/docker/workflow/client/DockerClient.java with the output of docker top shows the likely cause of that error:

      docker top prints the following fields

      UID                 PID                 PPID                C                   STIME               TTY                 TIME                CMD
      build               19799               19784               0                   22:23               pts/0               00:00:00            cat
      

      However, the Java client assumes that only PID, USER, TIME and COMMAND is printed. I suggest that the process list is determined by using an explicit format specifier like

      docker container top ${CONTAINER_ID} -eo pid,comm
      

        Attachments

          Issue Links

            Activity

            Hide
            jglick Jesse Glick added a comment -

            For specialized use cases like this you should not use withDockerContainer. Just run whatever docker commands you need directly from a sh (or indirectly via some script).

            Show
            jglick Jesse Glick added a comment - For specialized use cases like this you should not use withDockerContainer . Just run whatever docker commands you need directly from a sh (or indirectly via some script).
            Hide
            adnn Ad added a comment - - edited

            Well, we are using the Docker agent syntax:

            agent {
             docker {
               image 'ag/ubuntu-conan'
               args '''-v $DOCKERCONFIG_FOLDER/ag/ubuntu-conan.env:/dockerconfig.env
             }
            }
            
            stage('Use the tool') {
              steps {
                sh 'conan install whatever'
              }
            }

            Is not that the exact intended "tool-only" use case you were mentioning above? If not, what is the expected use-case for these kind of agents then?

            Show
            adnn Ad added a comment - - edited Well, we are using the Docker agent syntax: agent { docker { image 'ag/ubuntu-conan' args '''-v $DOCKERCONFIG_FOLDER/ag/ubuntu-conan.env:/dockerconfig.env } } stage( 'Use the tool' ) { steps { sh 'conan install whatever' } } Is not that the exact intended "tool-only" use case you were mentioning above? If not, what is the expected use-case for these kind of agents then?
            Hide
            jglick Jesse Glick added a comment -

            agent docker is just sugar for withDockerContainer. The expected use case is anything that happens to work the first time you try it. There is really no further guarantee than that.

            Show
            jglick Jesse Glick added a comment - agent docker is just sugar for withDockerContainer . The expected use case is anything that happens to work the first time you try it. There is really no further guarantee than that.
            Hide
            adnn Ad added a comment -

            For specialized use cases like this you should not use withDockerContainer. Just run whatever docker commands you need directly from a sh (or indirectly via some script).

            We are revisiting our use of docker agents in our CI pipeline. Jesse Glick we are considering following your advice above, thus removing the docker agents and instead run `docker` commands in `sh` steps directly on the master.

            Yet, our current setup is that we have a stage with many steps running on the agent (having the different steps showing nicely in Jenkins UI). How could we get the same result by executing the docker command directly? (i.e. executing discrete Jenkins `steps` in the same docker container, without restarting the container since it would loose its state).

            Show
            adnn Ad added a comment - For specialized use cases like this you should not use  withDockerContainer . Just run whatever  docker  commands you need directly from a  sh  (or indirectly via some script). We are revisiting our use of docker agents in our CI pipeline. Jesse Glick  we are considering following your advice above, thus removing the docker agents and instead run `docker` commands in `sh` steps directly on the master. Yet, our current setup is that we have a stage with many steps running on the agent (having the different steps showing nicely in Jenkins UI). How could we get the same result by executing the docker command directly? (i.e. executing discrete Jenkins `steps` in the same docker container, without restarting the container since it would loose its state).
            Hide
            jglick Jesse Glick added a comment -

            Ad that is indeed a missing feature in Pipeline. I have hijacked JENKINS-44847 to discuss this.

            Show
            jglick Jesse Glick added a comment - Ad that is indeed a missing feature in Pipeline. I have hijacked JENKINS-44847 to discuss this.

              People

              • Assignee:
                Unassigned
                Reporter:
                hendrikhalkow Hendrik Halkow
              • Votes:
                3 Vote for this issue
                Watchers:
                35 Start watching this issue

                Dates

                • Created:
                  Updated: