container pause status

[rajasec]

@crosbymichael @LK4D4 @mrunalp
When I've tried to get the container status whether it is paused or frozen, Eventhough it was paused by runc container.status always returns Running..
Current implementation look for
if c.config.Cgroups != nil && c.config.Cgroups.Freezer == configs.Frozen
c.config.Cgroups.Freezer always comes with empty, as it never got initialized with
any values in cgroup creation in spec.go ( also confirmed by looking freezer value in state.json).
Also realized that Freezer subsystem was never part of spec_linux.
Docker handles this situation by adding flag to true to container.Paused variable during container pause.
is runc going to have different implementation to check container status for pause situation.
For checking the container status, do we need to check by config value ( as per current implementation) or check the run time of cgroups freezer for the specific container

[wking]

On Thu, Aug 20, 2015 at 10:11:58PM -0700, Rajasekaran wrote:

For checking the container status, do we need to check by config
value ( as per current implementation) or check the run time of
cgroups freezer for the specific container

Since a config / state file can be stale, I think it makes more sense
to ask the kernel directly for the cgroups freezer status 1.
There's some discussion of state content vs. direct kernel lookups in
opencontainers/runtime-spec#41 and opencontainers/runtime-spec#87. With the
application's process ID:

$ ps -o cgroup 29285
CGROUP
8:perf_event:/oci-gentoo-minimal,7:freezer:/oci-gentoo-minimal,6:devices:/oci-gentoo-minimal,5:memory:/oci-gentoo-minimal,4:cpuacct:/oci-gentoo-minimal,3:cpu:/oci-gentoo-minimal,2:cpuset:/oci-gentoo-minimal
$ cat /sys/fs/cgroup/freezer/oci-gentoo-minimal/freezer.state
THAWED

[rajasec]

Thanks @wking for the confirmation
Exactly I'm working on the same thing to get the freezer state from cgroup instead of config file , will generate the PR shortly.

[mikebrow]

I also noted this bug when testing the new runc ps command. Seems the state in the state.json file should be updated upon successful state change no? Otherwise what's the point of the file?

[rajasec]

With new container state machine changes #311, this will get fixed.

On Tue, Nov 24, 2015 at 4:38 AM, Mike Brown notifications@github.com
wrote:

I also noted this bug when testing the new runc ps command. Seems the
state in the state.json file should be updated upon successful state change
no? Otherwise what's the point of the file?

—
Reply to this email directly or view it on GitHub
#217 (comment)
.

[rajasec]

Got fixed by #311
Closing this issue.