concourse: failed-to-find-created-volume-in-baggageclaim

Bug Report

  • Concourse version: 3.0.1
  • Deployment type (BOSH/Docker/binary): Docker
  • Infrastructure/IaaS: privately hosted virtual machine:
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=16.04
DISTRIB_CODENAME=xenial
DISTRIB_DESCRIPTION="Ubuntu 16.04.2 LTS"
NAME="Ubuntu"
VERSION="16.04.2 LTS (Xenial Xerus)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 16.04.2 LTS"
VERSION_ID="16.04"
HOME_URL="http://www.ubuntu.com/"
SUPPORT_URL="http://help.ubuntu.com/"
BUG_REPORT_URL="http://bugs.launchpad.net/ubuntu/"
VERSION_CODENAME=xenial
UBUNTU_CODENAME=xenial
  • Browser (if applicable): Chrome 58.0.3029.110 (64-bit)
  • Did this used to work? - Yes!

Error on checking resource (“checking failed”):

failed-to-find-created-volume-in-baggageclaim

This is an error on all types of resources (I currently use git and maven).

Possibly related issues: #896, #1171, #373

Workers:

fly -t ci workers
name          containers  platform  tags  team  state    version
084fa9e06b13  0           linux     none  none  running  1.0

What other data do you need?

Currently my whole CI is blocked by this. I don’t want to delete/restart anything until you inform me of additional data I should gather. This is actually a general question - how do I gather troubleshooting data? Where are the web/worker logs? My docker logs concourse-web/worker is polluted by pings and whatever. No use at all…

About this issue

  • Original URL
  • State: closed
  • Created 7 years ago
  • Reactions: 5
  • Comments: 26 (6 by maintainers)

Commits related to this issue

Most upvoted comments

We found that the volumes all disappear when vagrant is rebooted because work-dir is pointing to a tmp directory in concourse-lite. We changed it so it does not point to tmp here https://github.com/concourse/concourse-lite/commit/6e4600716726fd601a0e28356d6053fd1a6a08f6. But this only solves the problem for the vagrant box users getting the “failed to find created volume in baggageclaim”.

For everyone else that is running into this, can you leave a comment on how to reproduce this error with the way you deployed your workers? For example, is it that your workers always have a static name or do you have some configuration that makes this error happen every time you recreate your workers, etc.

It happened again, but this time disk space is not the issue.

Filesystem             Size  Used Avail Use% Mounted on
...
...docker_Concourse    8.8G  2.0G  6.3G  24% ...

Here is the worker list:

fly -t ci workers
name          containers  platform  tags  team  state    version
12107ccf8b9e  0           linux     none  none  running  1.0

The virtual machine hosting the docker that runs Concourse was rebooted (with reboot) about 20mins ago… Is there maybe an issue in stopping the concourse-worker container?

… later …

“Resolved” in the same way:

  1. stop worker container
  2. delete state
  3. start worker container
  4. prune stalled workers