Docker 容器正在运行，但其进程已完成

Question

I run my typescript application in a docker container. Sometimes it happens, that the application finishes, but the container is still in the running state. How is this even possible ? I was thinking that I forgot to catch a rejected Promise or forgot to close a stream, but in that case, docker top myContainer would say me, that the main process is still running, right ?

Docker ps:

docker ps
5c63b442af79        filipxxx/v2x_communication   "npm run start ether…"   2 hours ago         Up 2 hours        vehicle2

Docker top:

docker top vehicle2
UID                 PID                 PPID                C                   STIME  

Docker inspect:

docker inspect vehicle2
[
    {
        "Id": "5c63b442af799b8ff3b83d7c53e1ccfd2a290d469b58b10970217aa987e963f9",
        "Created": "2019-01-03T13:26:50.947651153Z",
        "Path": "npm",
        "Args": [
            "run",
            "start",
            "ethereum",
            "172.21.0.3:8545",
            "run-producer",
            "2",
            "100",
            "0xfb69fd63952d243fc235b91ff7bc49f9cd4a31f8"
        ],
        "State": {
            "Status": "running",
            "Running": true,
            "Paused": false,
            "Restarting": false,
            "OOMKilled": false,
            "Dead": false,
            "Pid": 46799,
            "ExitCode": 0,
            "Error": "",
            "StartedAt": "2019-01-03T13:33:52.860979672Z",
            "FinishedAt": "0001-01-01T00:00:00Z"
        },
...

Surprisingly when running docker exec -i vehicle2 echo 'hello world' , it returns me: cannot exec in a stopped state: unknown .

Below is the dockerfile, I used to build the image.

FROM node:8

WORKDIR /v2x_communication
COPY . /v2x_communication

RUN npm install && npm run build

ENTRYPOINT ["npm", "run"]

Even if I run docker stop vehicle2, it exits successfully, but the vehicle2 is still listed under docker ps and docker inspect vehicle2 is still saying that its in the running state.

Docker info:

Containers: 50
 Running: 48
 Paused: 0
 Stopped: 2
Images: 150
Server Version: 18.09.0
Storage Driver: overlay2
 Backing Filesystem: extfs
 Supports d_type: true
 Native Overlay Diff: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: bridge host macvlan null overlay
 Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
Swarm: active
 NodeID: sah8xlcjnxbq13uofznqrjs6e
 Is Manager: false
 Node Address: 10.132.0.5
 Manager Addresses:
  10.132.0.2:2377
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: c4446665cb9c30056f4998ed953e6d4ff22c7c39
runc version: 4fc53a81fb7c994640722ac585fa9ca548971871
init version: fec3683
Security Options:
 apparmor
 seccomp
  Profile: default
Kernel Version: 4.15.0-1026-gcp
Operating System: Ubuntu 18.04.1 LTS
OSType: linux
Architecture: x86_64
CPUs: 48
Total Memory: 94.41GiB
Name: vehicle-fleet-big-1
ID: OAVG:6QVR:EH3F:OYNO:ADC4:QDAN:R2AF:LSSV:2VSI:IJWJ:PJH2:LJVP
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
Labels:
Experimental: false
Insecure Registries:
 127.0.0.0/8
Live Restore Enabled: false
Product License: Community Engine

WARNING: No swap limit support

Answer 1

Either you've found a bug, or something is holding the container open. The closest issue I can find is rather old #30927 . I'd start investigating dockerd and OS logs to see if there are any errors you can find there. For dockerd, that's in journalctl -u docker for systemd environments. And on the OS, anything under /var/log for would be good to start debugging. Potential blockers I can imagine include:

• a failed shim process, perhaps a runc stuck in a zombie state
• a mount that will not release, something could be trying to read files in the docker filesystem
• commands querying the container that haven't exited, perhaps something pulling lots of logs that has hung waiting for a pipe / buffer to clear

If you can't find anything, an issue in the moby/moby repo may be appropriate, but without any logs of an error pointing back to why, or a way to reproduce, it will be difficult to fix.