Jenkins pipeline: the container started but didn't run the expected command.

[borgogelli]

When I use the jacobalberty/firebird:3.0.6 image on my Jenkins server, I get an error

The command is:

$ docker run -t -d -u 1001:1001 --link a26ac42ec9c72169b7498c6186d72bfaa70751447b9a32882b02557247df7f68:db -w /home/jenkins/workspace/iubar-firebird-sidecar-hello  -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ********  jacobalberty/firebird:3.0.6 cat

(please note the "cat" command at the end, which is added by Jenkins)

The error is:

$ docker top ce3f07d8bd10e9dd94c3cf7fe86e5e31257398d41e45f2cf5ad2060050a3bd5e -eo pid,comm
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, as required by official docker images (see https://github.com/docker-library/official-images#consistency for entrypoint consistency requirements).
Alternatively you can force image entrypoint to be disabled by adding option `--entrypoint=''`.

If I exchange the jacobalberty/firebird:3.0.6 image with the mysql:5 image, I get no errors.

Any advice ?

[jacobalberty]

That's interesting.

So the image definitely runs the cat command but because we forward SIGTERM to firebird we do some unusual trickery to make things work. let me merge pr #58 in and get it built, it may fix the issue... if it doesn't i have one other trick i can try.

Technically it is in compliance with the practice it's just got some additional requirements that may be breaking that test. I'll reply back in a bit when I get it built on the hub for you to try again.

I have a few overhauls I'm doing to tall of my docker images so now is a good time to try and catch this to clean it up.

[jacobalberty]

ok #58 is merged in and the build is done on the hub. Give it a try and let me know if it passes the jenkins test. If not I'll just have to add a special case for fbguard and just execute anything else directly

[borgogelli]

No way, the Jenkins job loops indefinitely. The Jenkins' "sidecar" pattern involves two calls to Docker's run comand. As you can see from the picture, the first is ok, while the second call loops indefinitely. If it could be useful, I can send you the credentials to access our Jenkins and Docker (Portainer) servers.

The Jenkins script is the following:

pipeline {
  agent none
  stages {
    stage('Run Tests') {
      environment {
        IMAGE1 = "alpine:latest"
        IMAGE2 = "jacobalberty/firebird:fbconsist"
      }
      parallel {
        stage("Dbms") {
          agent {
            label 'docker'
          }
          steps {
            script {
              docker.image("${env.IMAGE2}").withRun('-p 3051:3050 -e ISC_PASSWORD=masterkey -v /home/jenkins/firebird:/firebird/data:rw,z --name firebird') { c ->
                docker.image("${env.IMAGE2}").inside("--link ${c.id}:db --volumes-from firebird") {
                  // Wait until the service is up
                  sh 'while (! nc -v -z -w5 db 3050); do echo "..."; sleep 2; done'
                  sh 'echo "OK Firebird is running"'
                }
                docker.image("${env.IMAGE1}").inside("--link ${c.id}:db --volumes-from firebird") {
                  sh 'echo "Hello from Alpine. From here Firebird is running on the host db, port 3050"'
                }
              }
            }
          }
        }
      }
    }
  }
}

I'm very confused, the only hint is that the same script with the mysql:5 image works fine.

[borgogelli]

Well, I have taken a simpler approach (KISS). If I give up running commands on the firebird container, but just start and use it, then Jenkins' job is successful. So I end up to run only one firebird container and give up interacting with it from the terminal. It's a trade-off, but it works fine, looking forward to finding a full solution.

pipeline {
  agent none
  stages {
    stage('Run Tests') {
      environment {
        IMAGE1 = "maven:3.6-ibmjava-8-alpine"
        IMAGE2 = "jacobalberty/firebird:3.0.6"
      }
      parallel {
        stage("Dbms") {
          agent {
            label 'docker'
          }
          steps {
            script {
              docker.image("${env.IMAGE2}").withRun('-p 3051:3050 -e ISC_PASSWORD=masterkey -v /home/jenkins/firebird:/firebird/data:rw,z') {
                c ->docker.image("${env.IMAGE1}").inside("--link ${c.id}:db") {
                  sh 'while (! nc -v -z -w5 db 3050); do echo "..."; sleep 2; done'
                  sh 'echo "Ok, Firebird is running on the \'db\' host"'
                }
              }
            }
          }
        }
      }
    }
  }
}

[jacobalberty]

In about 10 minutes or so new builds with what I believe is the correct fix will appear on docker hub, the images just started building

[jacobalberty]

Oh yeah. The new fix is on 3.0.7 I did not update the 3.0.6 images. Judging by the release notes you really should move to 3.0.7 but if you absolutely must stay on 3.0.6 let me know and I'll backport the fix in a bit.

On Thu, Oct 22, 2020, 8:29 AM Andrea Borgogelli Avveduti < notifications@github.com> wrote:

Well, I have taken a simpler approach (KISS). If I give up running commands on the firebird container, but just start and use it, then Jenkins' job is successful. So I end up to run only one firebird container and give up interacting with it from the terminal. It's a trade-off, but it works fine, looking forward to finding a full solution.

pipeline { agent none stages { stage('Run Tests') { environment { IMAGE1 = "maven:3.6-ibmjava-8-alpine" IMAGE2 = "jacobalberty/firebird:3.0.6" } parallel { stage("Dbms") { agent { label 'docker' } steps { script { docker.image("${env.IMAGE2}").withRun('-p 3051:3050 -e ISC_PASSWORD=masterkey -v /home/jenkins/firebird:/firebird/data:rw,z') { c ->docker.image("${env.IMAGE1}").inside("--link ${c.id}:db") { sh 'while (! nc -v -z -w5 db 3050); do echo "..."; sleep 2; done' sh 'echo "Ok, Firebird is running on the \'db\' host"' } } } } } } } } }

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/jacobalberty/firebird-docker/issues/62#issuecomment-714494411, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAPDNAXBW3ZLAI4RU2TV3NTSMAXTXANCNFSM4SYR5YKA .

[jacobalberty]

Can you confirm if the latest and 3.0.7 tags have this issue fixed now?

[borgogelli]

The problem persists with the 3.0.7 version too.

I have also posted a Stackoverflow question to refine the solution proposed above which call the container only once.

[jacobalberty]

so just for giggles, try the sidecar pattern but drop the -u 1001:1001 from the sidecar

[jacobalberty]

jacobalberty/docker:fbconsist should fix this. I went ahead and moved all of the environment setup code into a separate function and only run it when launching the service itself. This way if you're running a command ala sidecar it will just be an environment with firebird cli stuff installed and working and leave the service stuff unconfigured.

[borgogelli]

Great, the Jenkins sidecar script above works as a charm with the jacobalberty/firebird:fbconsist image. Thank you very much. I think that solution will be useful to many users.

[jacobalberty]

I will go ahead and merge fbconsist into master and beta then

[borgogelli]

I will go ahead and merge fbconsist into master and beta then

Is firebird:3.0.7 different from firebird:latest or is it my error ? The second image works fine like the firebird:fbconsist, while the first one fails.

[jacobalberty]

@borgogelli I moved from docker hub builds to github actions, the version tagging action I used depends on tags with a v at the start to tag major and minor versions, so it's firebird:v3.0.7 now, README.md was updated to reflect that.

The mistake is mine I forgot to include the v when I mentioned the tag here. try v3.0.7 and let me know if it works please, sorry for the confusion.

[borgogelli]

Thank you very much again