0

I have a docker container on AWS EC2 instance :

$ docker ps                    
CONTAINER ID   IMAGE     COMMAND   CREATED   STATUS    PORTS     NAMES

$ docker ps -a                 
CONTAINER ID   IMAGE      COMMAND            CREATED        STATUS                     PORTS     NAMES
b78279ed9e51   gnumeric   "sleep infinity"   2 months ago   Exited (137) 4 weeks ago             gnumeric

$ docker exec gnumeric ps -ef
UID        PID  PPID  C STIME TTY          TIME CMD
1000         1     0  0 Jan15 ?        00:00:00 sleep infinity
1000      4861     0  0 21:31 ?        00:00:00 ps -ef

$ uname -a
Linux ip-10-0-2-199.ec2.internal 5.10.149-133.644.amzn2.x86_64 #1 SMP Tue Oct 18 16:52:42 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

$ docker version
Client:
 Version:           20.10.17
 API version:       1.41
 Go version:        go1.18.6
 Git commit:        100c701
 Built:             Wed Sep 28 23:10:17 2022
 OS/Arch:           linux/amd64
 Context:           default
 Experimental:      true

Server:
 Engine:
  Version:          20.10.17
  API version:      1.41 (minimum version 1.12)
  Go version:       go1.18.6
  Git commit:       a89b842
  Built:            Wed Sep 28 23:10:55 2022
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.6.6
  GitCommit:        10c12954828e7c7c9b6e0ea9b0c02b01407d3ae1
 runc:
  Version:          1.1.3
  GitCommit:        1e7bb5b773162b57333d57f612fd72e3f8612d94
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

Why can I run commands on a container with Exited status ?

Update

$ docker version # Windows
Client:
 Cloud integration: v1.0.29
 Version:           20.10.22
 API version:       1.41
 Go version:        go1.18.9
 Git commit:        3a2c30b
 Built:             Thu Dec 15 22:36:18 2022
 OS/Arch:           windows/amd64
 Context:           default
 Experimental:      true

Server: Docker Desktop 4.16.1 (95567)
 Engine:
  Version:          20.10.22
  API version:      1.41 (minimum version 1.12)
  Go version:       go1.18.9
  Git commit:       42c8b31
  Built:            Thu Dec 15 22:26:14 2022
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.6.14
  GitCommit:        9ba4b250366a5ddde94bb7c9d1def331423aa323
 runc:
  Version:          1.1.4
  GitCommit:        v1.1.4-0-g5fd4c4d
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0
Philippe
  • 20,025
  • 2
  • 23
  • 32
  • Why wouldn't you be able to? A container is just a collection of namespaces. It's not like a virtual machine where there's a kernel that's running or isn't; you spin up a process with the same filesystem namespace, the same process namespace, the same uid namespace, and there you are -- it's a process in that container, even if it's the only thing there. – Charles Duffy Feb 14 '23 at 20:19
  • ..and the container is Exited again! =) – Nikolaj Š. Feb 14 '23 at 20:26
  • When I try to exec on a stopped container, I get "Container xxxxxx is not running". That's on Docker 20.10.22 on Ubuntu – Hans Kilian Feb 14 '23 at 20:41
  • @HansKilian That's what I expected as well, but it's not what I got. – Philippe Feb 14 '23 at 21:29
  • @CharlesDuffy can you try to reproduce a docker container with `Exited` status and still be able to run commands in that container ? I added result of `docker exec gnumeric ps -ef` – Philippe Feb 14 '23 at 21:33
  • @Philippe I'm a bit surprised that `ps -ef` shows a process for `sleep`. – Hans Kilian Feb 14 '23 at 21:41
  • @Philippe, I can't personally: I don't use Docker these days (systemd-nspawn meets my needs adequately). But as someone who knows the underlying APIs, it's completely unsurprising that Docker _can and should_ be able to start a new process in namespaces identical to those previously used by a now-exited process; it would be much more surprising if it _couldn't_. Yes, it's a different codepath (you can't just attach to an existing process's instance of those namespaces but need to set them up again), but there's not anything difficult or nonobvious about what that code needs to do. – Charles Duffy Feb 14 '23 at 22:00
  • (so if they have a codepath intended to create an error in this scenario, it's a completely artificial limitation, not something innate to how namespace-based virtualization works under the hood) – Charles Duffy Feb 14 '23 at 22:03
  • @CharlesDuffy I pasted the result of `docker exec gnumeric ps -ef`, you can see it's running in the container which started almost a month ago. – Philippe Feb 14 '23 at 22:24
  • @CharlesDuffy Do you have a link to API which specify docker starts a new process in namespaces identical to those previously used by a now-exited process ? – Philippe Feb 14 '23 at 22:34
  • Um. The namespaces are defined by your Dockerfile -- you hash together the state changes made by your steps and you get the identifier for each interim state, then combine layers identified by those hashes to get your filesystem namespace; that's how it _works_; if you didn't use consistent hashes, you couldn't reuse a previously-built Docker container at all and Docker wouldn't be fit-to-purpose. Similarly, if you couldn't set up your user namespaces the same way between invocations the UIDs would change so files would look like they were owned by different users run-to-run, etc. – Charles Duffy Feb 14 '23 at 22:42
  • Which is to say -- everything I've been asserting falls out of the design fundamentals, which are _very_ well-documented. – Charles Duffy Feb 14 '23 at 22:42
  • I don't think namespaces are relevant here, the question is, for an "Exited" container, commands run where ? Do you have link to official docker documentation to support what you said ? – Philippe Feb 14 '23 at 22:56

0 Answers0