Builds getting killed with vague message: `Received signal killed`



I’m told to post in this room but the builds that get killed are private. I wonder how best I shall report details here.

For CircleCI employees that pass by, the builds are in getvero/mailship, and the branch is feature/circle-2.0.

This is the only line that shows up: Received signal killed. I’m quite at dead end here. It has happened for consecutive builds so it’s not intermittent.

Kill signal problem
Build ending with Received 'killed' signal

This is a legitimate problem. I’m asking internally if they have any idea. I couldn’t find any logs to provide further insight.


I am also seeing this same issue in one of our repositories. We seem to be ok on 3 of our apps that we’ve migrated to Circle 2, but one app consistently fails with this problem when running rspec. I can only seem to get it to consistently finish an rspec run maybe 15% of the time. One possible difference is that that app is trying to run in parallel – or at least, I’m trying to do so, but it doesn’t seem to split the rspec tests up.

Cached directory is not being restored

I still have not seen a definitive reason as to why this happens. Can you PM me an example build?

Unexpected preparation error: Internal Error - runner failed with exit code: 137

Just did. Thanks for taking a look! Let me know if you have any ideas.


I am wondering if this is related to Maven build failures that I am seeing, such as this build. It fails with exit code 137, which according to this thread indicates Maven got stopped by a SIGKILL signal.


This does seem like an OOM issue. Can you pass memory restrictions to the JVM? Do you have any insight into how much memory your builds generally use?


Right now I am setting the MAVEN_OPTS to 512 MB

but I have been to build locally with that set as low as 20 MB with this particular project (which is extremely small).


We have solved it. You need to overwrite the cmd for the base image.

- image: maven:3.3.9-jdk-8
  cmd: ["/bin/bash"]

I feel we should overwrite this by default moving forward.


Awesome, that fixed it.

Yeah, perhaps the first image, being the build container’s image, should always have its command overridden. It might need to be /bin/sh since some images (like alpine ones) don’t pre-install bash.


I’m not sure it is related but I’m also getting builds killed (on a private repository).

The project uses the docker executor with a node 9 image.

I believe a subprocess is getting killed as I see a Killed message mixed with the rest of the output.

The config file defines the image in jobs / build / docker instead of using containerInfo like @itzg’s file. But I couldn’t find containerInfo anywhere on the docs. Here is a portion of my config file:

version: 2
      - image: node:9
      - checkout
      # Versions Check
      - run:
          name: Node version
          command: node -v
      - run:
          name: Yarn version
          command: yarn --version


Are you OOMing? That config works fine as-is


Yes, the build is possibly OOMing!

But that’s not the full config, just the basic part containing the docker config. I was wondering how to apply the containerInfo / cmd from the solution using this syntax.


The containerInfo section was deprecated in favor of the docker section under a job declaration.

You can find the new command directive here under an image: