Currently start command will invoke getExitCode - which is based on
Inspect API - to get returned exit code after container exits.
There's two race conditions here:
if container is started with Restart Policy, there's chance that the
container is restarted quickly before it calls getExitCode, under such
circumstance, the exit code is wrong.
if container is started with --rm, it's possible that container is
removed before getExitCode, in this situation, you can't get correct
exit code either.
Replace getExitCode with waitExitOrRemoved can solve this problem.
Signed-off-by: Zhang Wei <zhangwei555@huawei.com>
This fix tries to fix the issue raised in #23716 where `docker start`
causes an error of `No such container:` if the container has been
renamed before `docker start` returns.
The issue is that `docker start` use container name passed at the
beginning to check for exit code at the end of the `docker start`.
This fix addresses the issue by always use container's `ID` to get
the information during `docker start`.
Additional integration tests have been added to cover this fix.
This fix fixes#23716.
Signed-off-by: Yong Tang <yong.tang.github@outlook.com>
1. Replace raw `docker inspect -f xxx` with `inspectField`, to make code
cleaner and more consistent
2. assert the error in function `inspectField*` so we don't need to
assert the return value of it every time, this will make inspect easier.
Signed-off-by: Zhang Wei <zhangwei555@huawei.com>
The purpose of this PR is for users to distinguish Docker errors from
contained command errors.
This PR modifies 'docker run' exit codes to follow the chroot standard
for exit codes.
Exit status:
125 if 'docker run' itself fails
126 if contained command cannot be invoked
127 if contained command cannot be found
the exit status otherwise
Signed-off-by: Sally O'Malley <somalley@redhat.com>
Part of #16756
Use c.Assert instead of condition judgement in
integration-cli/docker_cli_start_test.go
Signed-off-by: Zhang Wei <zhangwei555@huawei.com>
Signed by all authors:
Signed-off-by: Michael Crosby <crosbymichael@gmail.com>
Signed-off-by: Arnaud Porterie <arnaud.porterie@docker.com>
Signed-off-by: David Calavera <david.calavera@gmail.com>
Signed-off-by: Jeff Lindsay <progrium@gmail.com>
Signed-off-by: Alexander Morozov <lk4d4@docker.com>
Signed-off-by: Luke Marsden <luke@clusterhq.com>
Signed-off-by: David Calavera <david.calavera@gmail.com>
Changed method declaration. Fixed all calls to dockerCmd
method to reflect the change.
resolves#12355
Signed-off-by: bobby abbott <ttobbaybbob@gmail.com>
The cli now doesn't echo the container ID when started using either -a
or -i. Also fixes `TestStartAttachCorrectExitCode` which incorrectly
called start with the result of wait rather than the container ID.
Signed-off-by: Arnaud Porterie <arnaud.porterie@docker.com>
Running parseVolumesFromSpec on all VolumesFrom specs before initialize
any mounts endures that we don't leave container.Volumes in an
inconsistent (partially initialized) if one of out mount groups is not
available (e.g. the container we're trying to mount from does not
exist).
Keeping container.Volumes in a consistent state ensures that next time
we Start() the container, it'll run prepareVolumes() again.
The attached test demonstrates that when a container fails to start due
to a missing container specified in VolumesFrom, it "remembers" a Volume
that worked.
Fixes: #8726
Signed-off-by: Thomas Orozco <thomas@orozco.fr>
when a container failed to start, saves the error message into State.Error so
that it can be retrieved when calling `docker inspect` instead of having to
look at the log
Docker-DCO-1.1-Signed-off-by: Daniel, Dao Quang Minh <dqminh89@gmail.com> (github: dqminh)
When doing `docker start -a` on a container that won't start, terminal
was getting stuck on the attach, even after container removal.
Docker-DCO-1.1-Signed-off-by: Brian Goff <cpuguy83@gmail.com> (github: cpuguy83)
