0

I have been unsuccessful running a docker container with systemd from a jenkins pipeline without getting the following error message:

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=''`.

Pipeline:

pipeline {
    agent {
        docker {
            image "centos/systemd"
            args "--entrypoint='/usr/sbin/init' -u root -v /sys/fs/cgroup:/sys/fs/cgroup --privileged"
        }
    }
    options {
        ansiColor('xterm')
        skipDefaultCheckout(true)
        timestamps ()
    }
    stages {
        stage('Test systemctl') {
            steps {
                sh ' systemctl' }
        }
        }
    }

It seems that jenkins is stealing any option of a CMD arg and putting in cat. Which seems foolish because /usr/sbin/init needs to be the first thing run. Ideally as the CMD.

1 Answer 1

2

It seems that jenkins is stealing any option of a CMD arg and putting in cat

Indeed I think this is what Jenkins is doing. It comes down to how they have designed their docker support. The container is started with a program that does nothing, so that they can run various commands inside it, via docker exec mechanisms. This is good for most use cases, because the command itself can fail without taking out the whole container with it.

For your systemd user case, maybe you should consider to use the Jenkins sidecar container support: https://www.jenkins.io/doc/book/pipeline/docker/#running-sidecar-containers.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.