Answers: <blockquote>
  <p>It seems that jenkins is stealing any option of a CMD arg and putting in cat</p>
  </blockquote>
  <p>Indeed I think this <em>is</em> 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 <code>docker exec</code> mechanisms. This is good for most use cases, because the command itself can fail without taking out the whole container with it.</p>
  <p>For your systemd user case, maybe you should consider to use the Jenkins sidecar container support: <a href="https://www.jenkins.io/doc/book/pipeline/docker/#running-sidecar-containers" rel="nofollow noreferrer">https://www.jenkins.io/doc/book/pipeline/docker/#running-sidecar-containers</a>.</p>
  
Answers: CC BY-SA 4.0
Answers: 2021-11-16T19:41:10.907Z
Answers: 2021-11-16T19:41:10.907Z
Answers: Segfault
Body: <p>I have been unsuccessful running a docker container with systemd from a jenkins pipeline without getting the following error message:</p>
  <pre><code>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=''`.
  </code></pre>
  <p>Pipeline:</p>
  <pre><code>pipeline {
      agent {
          docker {
              image &quot;centos/systemd&quot;
              args &quot;--entrypoint='/usr/sbin/init' -u root -v /sys/fs/cgroup:/sys/fs/cgroup --privileged&quot;
          }
      }
      options {
          ansiColor('xterm')
          skipDefaultCheckout(true)
          timestamps ()
      }
      stages {
          stage('Test systemctl') {
              steps {
                  sh ' systemctl' }
          }
          }
      }
  </code></pre>
  <p>It seems that jenkins is stealing any option of a <code>CMD</code> arg and putting in <code>cat</code>. Which seems foolish because <code>/usr/sbin/init</code> needs to be the first thing run. Ideally as the <code>CMD</code>.</p>
  
Tags: <docker><jenkins><jenkins-pipeline>
Title: Can one run a docker container with systemd from a jenkins pipeline?
UserDisplayName: collin_tgz
ThreadText: # Can one run a docker container with systemd from a jenkins pipeline?
  
  (Asked by: username_0 on 2021-11-16)
  
  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`.
  
  **Tags:** docker, jenkins, jenkins-pipeline
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2021-11-16. Score: 2 | Accepted answer
  
  > 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>.
  
  
  ---
  
  