<p>I suspect this may be something coming from containerd changes - running PCF 2.5 the runc list works fine, 2.6 runc list shows nothing in the inventory.  I have <em>not</em> yet found the equivalent command that will allow me to find the container id and how to execute a shell entry to that container instance yet, but I'm hot on the trail.</p>

CC BY-SA 4.0
2019-09-12T15:21:07.950Z
Found it (and confirmed it is new containerd behavior [for me, at least]):

After bosh ssh'ing and sudo'ing cell where the instance is running:
app_guid=<app_guid value from `cf app <app_name> --guid`>
cell_name=<string of the diego cell guid you're on>
cfdot actual-lrp-groups | grep $app_guid |grep $cell_name| jq '.instance | {instance_guid, cell_id, process_guid}'
Take the result instance_guid and
containerid=<instance_guid>
/var/vcap/packages/containerd/bin/ctr -a /var/vcap/sys/run/containerd/containerd.sock -n garden tasks exec --exec-id my-shell --tty $containerid /bin/bash
Jon Ravenscraft
CC BY-SA 4.0
2019-09-12T15:26:01.647Z
See https://github.com/cloudfoundry/garden-runc-release/blob/develop/docs/opsguide-containerd.md
Jon Ravenscraft
CC BY-SA 4.0
2019-09-13T08:05:26.943Z
Amazing :)..This works
Vipin Menon
CC BY-SA 4.0
2019-09-12T14:31:14.013Z
2019-09-12T14:31:14.013Z
Jon Ravenscraft
<p>What @Jon Ravenscraft posted as a comment on his own accepted (non) answer did in fact work for me as a solution. I am just formatting it here as an answer for anybody who stumbles here in the future:</p>
<ul>
<li>Follow <a href="https://community.pivotal.io/s/article/How-to-get-into-an-App-Container-Manually-with-Garden-RunC-Backend?language=en_US" rel="nofollow noreferrer">these steps</a> to get instance GUID (also included below for convenience)</li>
</ul>
<pre class="lang-bash prettyprint-override"><code># Establish the process-guid for the app:
cf curl /v2/apps/$(cf app &lt;app_name&gt; --guid)| jq -r '.metadata.guid + &quot;-&quot; + .entity.version'
b06b2901-2093-4be4-9f37-f7788d04ce8c-ff93f0e2-285f-4f18-a6fc-806802f3dde9

# Find the hosts where the app instances are running:
cf curl v2/apps/$(cf app &lt;app-name&gt; --guid)/stats | grep host

# Identify the Diego cell you want to ssh to by running bosh vms | grep &lt;cell_ip&gt;

# bosh ssh to the Diego cell (grab the cell_id from step 3).

# Once in the Diego cell, as root, run the following command to grab the container_guid/instance_guid:
cfdot actual-lrp-groups-for-guid &lt;process_guid_from_step_1&gt; | jq '.instance | select (.address == &quot;&lt;diego_cell_ip&gt;&quot;)' | jq .instance_guid
</code></pre>
<ul>
<li>Then, from your terminal on the appropriate diego cell:</li>
</ul>
<pre class="lang-bash prettyprint-override"><code>sudo /var/vcap/packages/containerd/bin/ctr -a /var/vcap/sys/run/containerd/containerd.sock -n garden tasks exec --exec-id my-shell --tty &lt;instance-guid&gt; /bin/sh
</code></pre>
<p>And voilà , you are dropped at a shell...</p>
<p>P.S. I believe the speculated reasoning given in the other answer is in fact, also correct, per <a href="https://docs.pivotal.io/pivotalcf/2-6/pcf-release-notes/runtime-rn.html" rel="nofollow noreferrer">https://docs.pivotal.io/pivotalcf/2-6/pcf-release-notes/runtime-rn.html</a>:</p>
<blockquote>
<p>PAS v2.6 enables containerd mode by default to bring PAS in line with other container providers. When you upgrade to PAS v2.6, Garden switches the container runtime from runc to containerd. Since the restart of Garden and the re-creation of containers are a normal part of a PAS upgrade, there is no operational impact to running applications.</p>
</blockquote>

CC BY-SA 4.0
2021-04-26T15:55:07.730Z
2021-04-26T16:45:20.700Z
2021-04-26T16:45:20.700Z
pooley1994
<p>So I have been trying <a href="https://community.pivotal.io/s/article/How-to-get-into-an-App-Container-Manually-with-Garden-RunC-Backend" rel="nofollow noreferrer">this-tutorial</a> to access the runC container from the diego-cell VM. However, when I try to run </p>

<pre><code>/var/vcap/packages/runc/bin/runc exec -t &lt;instance_id&gt; /bin/bash
</code></pre>

<p>I get the error</p>

<pre><code>exec failed: container "&lt;id&gt;" does not exist
</code></pre>

<p>when I run cfdot for the given application it does list this instance-id,
also when navigating into the location</p>

<p><code>/var/vcap/data/garden/depot/&lt;container_id&gt;</code> it exists.</p>

<p>But runc in unable to open the container, also when I run</p>

<pre><code>runc list
</code></pre>

<p>the list of running containers in the vm is empty</p>

<pre><code>diego-cell/49dbeca6-36eb-4910-94b9-48960891a0b1:~# /var/vcap/packages/runc/bin/runc list
ID          PID         STATUS      BUNDLE      CREATED     OWNER
diego-cell/49dbeca6-36eb-4910-94b9-48960891a0b1:~#
</code></pre>

<p>I've run all as root as mentioned in the link.</p>

<p>Why am I not able to access the runC containers, What am I missing?</p>

<p>P.S: Although the intent is same, I'm not looking for cf ssh</p>

CC BY-SA 4.0
2019-06-25T16:35:37.240Z
What if you run `ps aux` and look at the running processes? Do you see the processes for your app running? Also, what version of Cloud Foundry are you running?
Daniel Mikusa
CC BY-SA 4.0
2019-06-26T06:35:46.863Z
Oh forgot to add that..Yes it shows the relevant process running
Vipin Menon
CC BY-SA 4.0
2019-06-26T15:27:07.143Z
What's odd is that `runc list` is showing nothing. Do you see this on all your Cells or just a specific Cell? Again, what versions are you running? Pivotal CF or OSS CF? Definitely include diego & garden release version being used.
Daniel Mikusa
CC BY-SA 4.0
2019-06-27T08:36:58.543Z
It maybe because it is a custom modified release of CF built in-house. Garden Release is 1.17.1 and Diego is 2.16
The CF has been broken to 3 separate deployments (1st deployment having cf and its components including diegoAPI) the second and third deployment is just for diegocells
Vipin Menon
CC BY-SA 4.0
2019-06-27T14:08:29.643Z
OK, not sure I can help much with a custom deployment. My only suggestion would be to compare to a foundation installed using cf-deployment, and look for differences in your deployment, release versions & in how the Cells are deployed & configured.
Daniel Mikusa
<containers>
How to get into an App Container Manually with Garden-RunC Backend?
Vipin Menon
# How to get into an App Container Manually with Garden-RunC Backend?

(Asked by: username_0 on 2019-06-25)

So I have been trying this-tutorial to access the runC container from the diego-cell VM. However, when I try to run 
/var/vcap/packages/runc/bin/runc exec -t  /bin/bash

I get the error
exec failed: container "" does not exist

when I run cfdot for the given application it does list this instance-id,
also when navigating into the location
/var/vcap/data/garden/depot/ it exists.
But runc in unable to open the container, also when I run
runc list

the list of running containers in the vm is empty
diego-cell/49dbeca6-36eb-4910-94b9-48960891a0b1:~# /var/vcap/packages/runc/bin/runc list
ID          PID         STATUS      BUNDLE      CREATED     OWNER
diego-cell/49dbeca6-36eb-4910-94b9-48960891a0b1:~#

I've run all as root as mentioned in the link.
Why am I not able to access the runC containers, What am I missing?
P.S: Although the intent is same, I'm not looking for cf ssh

**Tags:** containers

> **Comments:**
> **username_1**: What if you run `ps aux` and look at the running processes? Do you see the processes for your app running? Also, what version of Cloud Foundry are you running?  
> **username_0**: Oh forgot to add that..Yes it shows the relevant process running  
> **username_1**: What's odd is that `runc list` is showing nothing. Do you see this on all your Cells or just a specific Cell? Again, what versions are you running? Pivotal CF or OSS CF? Definitely include diego & garden release version being used.  
> **username_0**: It maybe because it is a custom modified release of CF built in-house. Garden Release is 1.17.1 and Diego is 2.16 The CF has been broken to 3 separate deployments (1st deployment having cf and its components including diegoAPI) the second and third deployment is just for diegocells  
> **username_1**: OK, not sure I can help much with a custom deployment. My only suggestion would be to compare to a foundation installed using cf-deployment, and look for differences in your deployment, release versions & in how the Cells are deployed & configured.  

---

## 2 answers

### Answer by username_2 on 2019-09-12. Score: 1 | Accepted answer

I suspect this may be something coming from containerd changes - running PCF 2.5 the runc list works fine, 2.6 runc list shows nothing in the inventory. I have *not* yet found the equivalent command that will allow me to find the container id and how to execute a shell entry to that container instance yet, but I'm hot on the trail.

> **Comments:**
> **username_2**: Found it (and confirmed it is new containerd behavior [for me, at least]):  After bosh ssh'ing and sudo'ing cell where the instance is running: app_guid=<app_guid value from `cf app <app_name> --guid`> cell_name=<string of the diego cell guid you're on> cfdot actual-lrp-groups | grep $app_guid |grep $cell_name| jq '.instance | {instance_guid, cell_id, process_guid}' Take the result instance_guid and containerid=<instance_guid> /var/vcap/packages/containerd/bin/ctr -a /var/vcap/sys/run/containerd/containerd.sock -n garden tasks exec --exec-id my-shell --tty $containerid /bin/bash  
> **username_2**: See https://github.com/cloudfoundry/garden-runc-release/blob/develop/docs/opsguide-containerd.md  
> **username_0**: Amazing :)..This works  

---

### Answer by username_3 on 2021-04-26. Score: 0

What @username_2 posted as a comment on his own accepted (non) answer did in fact work for me as a solution. I am just formatting it here as an answer for anybody who stumbles here in the future:

Follow these steps to get instance GUID (also included below for convenience)

# Establish the process-guid for the app:
cf curl /v2/apps/$(cf app  --guid)| jq -r '.metadata.guid + "-" + .entity.version'
b06b2901-2093-4be4-9f37-f7788d04ce8c-ff93f0e2-285f-4f18-a6fc-806802f3dde9

# Find the hosts where the app instances are running:
cf curl v2/apps/$(cf app  --guid)/stats | grep host

# Identify the Diego cell you want to ssh to by running bosh vms | grep 

# bosh ssh to the Diego cell (grab the cell_id from step 3).

# Once in the Diego cell, as root, run the following command to grab the container_guid/instance_guid:
cfdot actual-lrp-groups-for-guid  | jq '.instance | select (.address == "")' | jq .instance_guid


Then, from your terminal on the appropriate diego cell:

sudo /var/vcap/packages/containerd/bin/ctr -a /var/vcap/sys/run/containerd/containerd.sock -n garden tasks exec --exec-id my-shell --tty  /bin/sh

And voilà , you are dropped at a shell...
P.S. I believe the speculated reasoning given in the other answer is in fact, also correct, per https://docs.pivotal.io/pivotalcf/2-6/pcf-release-notes/runtime-rn.html:

PAS v2.6 enables containerd mode by default to bring PAS in line with other container providers. When you upgrade to PAS v2.6, Garden switches the container runtime from runc to containerd. Since the restart of Garden and the re-creation of containers are a normal part of a PAS upgrade, there is no operational impact to running applications.


---

