Skip to content

Spurious failure when starting docker on Travis #39035

Closed

Description

@alexcrichton

I've seen this error a number of times when docker is starting on Travis:

The command "if [ "$ALLOW_PR" = "" ] && [ "$TRAVIS_BRANCH" != "auto" ]; then
    echo skipping, not a full build;
elif [ "$TRAVIS_OS_NAME" = "osx" ]; then
    travis_retry git submodule update --init &&
    src/ci/run.sh;
else
    travis_retry git submodule update --init &&
    src/ci/docker/run.sh $IMAGE;
fi
" exited with 129.

notably the "exited with 129"

This looks similar to moby/moby#18948, but I haven't been able to figure out a fix for this...

Example logs:

Activity

  1. added
    A-spuriousArea: Spurious failures in builds (spuriously == for no apparent reason)
    on Jan 13, 2017
  2. aidanhs commented on Jan 13, 2017

    @aidanhs
    Contributor

    docker/compose#3379 (comment)

    Worth trying to remove --tty? Not sure what requires it in the rust build. It's a little odd because all these users are talking about docker exec, so might also be worth adding set -x.

  3. alexcrichton commented on Jan 13, 2017

    @alexcrichton
    MemberAuthor

    Interesting! My guess (don't know for sure) is that this is what's failing --

    exec docker \
    run \
    --volume "$root_dir:/checkout:ro" \
    --volume "$root_dir/obj:/checkout/obj" \
    --workdir /checkout/obj \
    --env SRC=/checkout \
    $args \
    --env CARGO_HOME=/cargo \
    --env LOCAL_USER_ID=`id -u` \
    --volume "$HOME/.cargo:/cargo" \
    --interactive \
    --tty \
    rust-ci \
    /checkout/src/ci/run.sh

    We could try removing --tty, yeah, as it's basically just there to give us pretty colors. It's not worth spurious failures though if that's the cause! @aidanhs want to send a PR removing that?

  4. alexcrichton commented on Jan 13, 2017

    @alexcrichton
    MemberAuthor

    Attempted PR to fix this is at #39036, let's wait awhile and see if this error still pops up after that merges.

  5. aidanhs commented on Feb 2, 2017

    @aidanhs
    Contributor

    @alexcrichton seen it recently?

  6. alexcrichton commented on Feb 2, 2017

    @alexcrichton
    MemberAuthor

    Nope!

  7. alexcrichton commented on Feb 2, 2017

    @alexcrichton
    MemberAuthor

    Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-spuriousArea: Spurious failures in builds (spuriously == for no apparent reason)

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions