All of our builds started failing this morning with this error - We haven’t made any recent adjustments to our circleci configs
"CircleCI was unable to run the job runner because we were unable to execute commands in build container.
This typically means that the build container entrypoint or command is terminating the container prematurely, or interfering with executed commands. Consider clearing entrypoint/command values and try again."
Any thoughts on where to start debugging?
I don’t have ideas, but we’re having the same issue. I filed a support ticket and I can update you if I hear anything back.
I’ve had the same problem and been banging my head against the wall all evening for this. What’s going here?
Thanks - nice to know its not only us
I also put in a support req and will followup
I am super confused by this error. Having the same problem since morning, but somehow the status page for CircleCi stays all green.
Have created a support ticket. Would appreciate any fix.
We are also having this issue 
Any updates would be super useful.
I have tried a few things.
For my environment
If I disable the /sbin/init command the generic error message goes away, but my build still fails as the infrastructure is not up.
I believe that the problem lies with setting up of container.
I did try different containers but no luck yet. If i initiate all the processes the build fails.
Hoping Circle CI will fix this quickly.
Out of curiosity, did you all use the automated migration for the Circle v1 to v2 configuration? The two projects in different orgs running into this were both migrated that way, and I’m wondering if the images are still valid.
Example:
docker:
- image: circleci/build-image:ubuntu-14.04-XXL-upstart-1189-5614f37
command: /sbin/initYes I have exactly that image. It was working perfectly fine till yesterday.
The image in itself works fine. There is something funny going on when you initiate all the processes using
/sbin/init
If you remove that command the container will spin up correctly.
@ericlutley Thanks It works like a charm.
We use the same image (circleci/build-image:ubuntu-14.04-XXL-upstart-1189-5614f37) and started running into the same error today.
Removing the /sbin/init command allowed the container to spin up. The tests initially failed because Postgresql was no longer running, but we were able to manually start it with
run: sudo service postgresql start. After this our tests passed again.
I don’t know why the container stopped running all of a sudden this morning, despite us having made no changes. But at least we’ve been able to work around the problem.
We had to add the postgresql start command as well. That worked great!
We use the same image ( circleci/build-image:ubuntu-14.04-XXL-upstart-1189-5614f37 ) and started running into the same issue from yesterday evening.
Container spin off worked fine after removing /sbin/init, but few of the tests are still failing.
Removing /sbin/init and adding the - run: sudo service postgresql start step worked for me too. I have no idea why.
Unfortunately the reply from CircleCI wasn’t as helpful to identifying the root cause.
Thanks for your patience while we investigate this issue. In looking at your build link, it appears the image you are using
circleci/build-image:ubuntu-14.04-XXL-*has not been updated in two years. This image was created to help users easily migrate from 1.0 to 2.0, but is bloated and does not offer the best performance as it is not maintained.For better performance and regular updates, we suggest using one of the CircleCI prebuilt images (https://circleci.com/docs/2.0/circleci-images/). These images actively maintained and always updated with the latest releases and fixes.
Additionally, you may want to consider using a custom image (https://circleci.com/docs/2.0/custom-images/).
After switching the job’s image, can you let us know if you’re able to run a job successfully? Looking forward to your response!
Anyone have any luck with this yet? We have removed the /sbin/init command and manually started mysql but a few things aren’t working then like phpunit and behat testing.
I’m having the same problem… removing /sbin/init command makes the container start, but then the built-in services that we need to have running aren’t running.
It sounds like Circle is trying to encourage people to switch to one of their new pre-built images, but I’m trying to avoid that because our production server runs Ubuntu and I don’t see any pre-built images running Ubuntu on Circle’s list, and my CI suite would be less dependable running on a different OS from my application.
@mustangJaro yep we got the same response
With the /sbin/init removal we got the image up, but we had issues with various other services. Namely x11 service not running
We have went ahead and started to re-build using their base images.
Our stack is python 2.7, node/npm, w/ node-browsers for testing, mysql, and memcached
Hello everyone.
This was caused by a change to fix a bug with the mongodb service image, which was running into a problem with zombie processes.
The fix in this case was to run docker containers with the --init flag enabled, which causes docker to run a tini init process as PID1. We expected this not to cause any issues, but as it turns out, more people run init daemons inside their containers than we expected.
In most cases, your best bet for long term stability and upgrades will be to use a list of individually versioned containers that run the same versions of each dependency as your production system. CircleCI produces a number of pre-built containers for use, but we don’t restrict you to using those.
We will be looking into a way to support the mongodb container as well as containers which need to run their own init daemon, but until then I would recommend the following:
command: /sbin/init linecircleci/build-image container image, as it is no longer being updated
ubuntu specifically, you should be able to use any Ubuntu derived container Docker Hub
I hope that helps provide some context for why this happened.
I removed the command: /sbin/init and now I am getting error for Redis. Please look at the image attached. As a workaround I tried command: ‘sudo redis-cli ping >/dev/null 2>&1 || sudo redis-server --daemonize yes’ and it sort of worked.
However, I am not sure using daemonize yes has any severe downside effects?
Please check the config file attached too.
version: 2
jobs:
build_and_test:
working_directory: ~/hcmed/hitch-health
parallelism: 1
shell: /bin/bash --login
environment:
CIRCLE_ARTIFACTS: /tmp/circleci-artifacts
CIRCLE_TEST_REPORTS: /tmp/circleci-test-results
docker:
- image: circleci/build-image:ubuntu-14.04-XXL-upstart-1189-5614f37
steps:
- checkout
- run: mkdir -p $CIRCLE_ARTIFACTS $CIRCLE_TEST_REPORTS
- run: sudo service postgresql start
- run:
working_directory: ~/hcmed/hitch-health
command: 'sudo redis-cli ping >/dev/null 2>&1 || sudo systemctl start redis;'
- restore_cache:
keys:
- v1-dep-{{ .Branch }}-
- v1-dep-develop-
- run: echo -e "export RAILS_ENV=test\nexport RACK_ENV=test" >> $BASH_ENV
- run: 'bundle check --path=vendor/bundle || bundle install --path=vendor/bundle
--jobs=4 --retry=3 '
- save_cache:
key: v1-dep-{{ .Branch }}-{{ epoch }}
paths:
- vendor/bundle
- ~/virtualenvs
- ~/.m2
- ~/.ivy2
- ~/.bundle
- ~/.go_workspace
- ~/.gradle
- ~/.cache/bower
- run: |-
mkdir -p config && echo 'test:
database: circle_ruby_test
pool: 15
encoding: unicode
adapter: postgresql
username: ubuntu
host: localhost
' > config/database.yml
- run:
command: bundle exec rake db:create db:schema:load --trace
environment:
RAILS_ENV: test
RACK_ENV: test
- run: RAILS_ENV=test bundle exec rspec -r rspec_junit_formatter --format RspecJunitFormatter -o $CIRCLE_TEST_REPORTS/rspec/junit.xml
- store_test_results:
path: /tmp/circleci-test-results
- store_artifacts:
path: /tmp/circleci-artifacts
- store_artifacts:
path: /tmp/circleci-test-results
deploy_to_master:
machine:
enabled: true
working_directory: ~/hcmed/hitch-health
steps:
- checkout
- run:
name: Deploy Master to Aptible
command: |
git push git@beta.aptible.com:hitch-health/hitch-health-stage.git $CIRCLE_SHA1:master
deploy_to_develop:
machine:
enabled: true
working_directory: ~/hcmed/hitch-health
steps:
- checkout
- run:
name: Deploy Develop to Aptible
command: |
git push git@beta.aptible.com:hitch-health/hitch-health-prod.git $CIRCLE_SHA1:master
workflows:
version: 2
build_test_and_deploy:
jobs:
- build_and_test
- deploy_to_master:
requires:
- build_and_test
filters:
branches:
only: master
- deploy_to_develop:
requires:
- build_and_test
filters:
branches:
only: developdaemonize will work fine.
Another option is to use a background step which runs redis without daemonizing - that has the added advtantage of making the stdout logs available to you.
https://circleci.com/docs/2.0/configuration-reference/#background-commands
You can also run a redis container separately, which should make it easy to run the same version of redis as you’re using in production: https://circleci.com/docs/2.0/executor-types/#using-multiple-docker-images