Bug 1204620

Summary: container stays around without any processes in it
Product: [Fedora] Fedora Reporter: Marius Vollmer <mvollmer>
Component: dockerAssignee: Lokesh Mandvekar <lsm5>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 22CC: adimania, admiller, dwalsh, golang-updates, hushan.jia, ichavero, jchaloup, jperrin, lsm5, mattdm, mgoldman, miminar, s, thrcka, vbatts
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-02-16 20:10:09 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1204627    
Attachments:
Description Flags
Setup script for reproducing none

Description Marius Vollmer 2015-03-23 08:08:37 UTC
Created attachment 1005245 [details]
Setup script for reproducing

Description of problem:

When running a specific custom image (see attachement), docker fails to notice when the single process exits.  The container stays around, and attempts to stop or remove it result in errors.

Doing the same with a slightly older version of docker shows expected behavior.

Version-Release number of selected component (if applicable):
docker-io-1.5.0-19.git5d7adce.fc22.x86_64

How reproducible:
Always.

Steps to Reproduce:
1. Run the attached SETUP script in an empty directory
2. Run the resulting image
   # docker run --name=probe cp /bin/container-probe
3. After wrestling control back from the hanging "docker run",
   try to stop or remove the container.
   # docker stop probe
   # docker rm -f probe

Actual results:

The expected output of container-probe is shown, but "docker run ..." does not return to the command line prompt.  In fact, job control doesn't work anymore either (C-c, C-z, C-\).

Stopping and removing leads to these errors:

# docker stop probe
Error response from daemon: Cannot stop container probe: active container for c492b7203b3d465c778935f97a12b3bf8a4c442731c7fd25cee6f50798ac4f65 does not exist
FATA[0000] Error: failed to stop one or more containers

# docker rm -f probe
Error response from daemon: Could not kill running container, cannot remove - active container for c492b7203b3d465c778935f97a12b3bf8a4c442731c7fd25cee6f50798ac4f65 does not exist
FATA[0000] Error: failed to remove one or more containers

Expected results:
The output is shown and "docker run" terminates successfully, the container is show as "exited" and can be removed.


Additional info:
docker-io-1.5.0-1.fc21.x86_64 shows the expected behavior.

"docker run -i" return control to the shell, but the resulting container can't be stopped or removed either.

"systemctl restart docker" puts the "probe" container into a state where it can be removed.

Comment 1 Marius Vollmer 2015-03-23 08:19:47 UTC
Replacing "FROM scratch" with "FROM busybox" shows the same behavior.

Comment 2 Fedora Admin XMLRPC Client 2015-03-24 03:54:04 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 3 Daniel Walsh 2015-04-14 18:36:31 UTC
This is working fine for me with docker-1.6

So I will mark this as modified.

Comment 4 Marius Vollmer 2015-04-21 07:34:54 UTC
(In reply to Daniel Walsh from comment #3)
> This is working fine for me with docker-1.6

Yes, our tests are passing again with docker 1.6.

We have changed the tests to avoid a statically linked binary, so this is no sure indication that the original bug has been fixed, but we are happy in any case.

Comment 5 Lokesh Mandvekar 2016-02-16 20:10:09 UTC
Closing this, as the latest stable is 1.9. Marius, please re-open if you see this issue at all with newer versions.

Comment 6 Marius Vollmer 2016-02-17 09:25:04 UTC
> Closing this, as the latest stable is 1.9. Marius, please re-open if you see this issue at all with newer versions.

I trust that there is now a regression test for this in Docker. :-)