Runc kill

[crosbymichael]

Closes #176
Closes #124

This is a carry of #176 with fixed cross compile.

@rajasec thanks, i have you commits included in this PR.

[LK4D4]

linux kill command also supports lowercase, so maybe strings.ToUpper first?

[crosbymichael]

@LK4D4 added the ToUpper

[LK4D4]

LGTM

[mrunalp]

LGTM

[rajasec]

@crosbymichael
Thanks

[apatil]

What are the intended cleanup semantics of runc kill vs killing the container by killing its process 1? Should I expect runc to remove all kernel state that was set up to support the container in either case or both cases, and does it depend on which signal I send?

On version 48fdc50, when I did runc kill 9 root, I saw:

# runc start
ERRO[0019] Failed to remove paths: map[devices:/sys/fs/cgroup/devices/user/1000.user/22.session/root cpuacct:/sys/fs/cgroup/cpuacct/user/1000.user/22.session/root perf_event:/sys/fs/cgroup/perf_event/user/1000.user/22.session/root freezer:/sys/fs/cgroup/freezer/user/1000.user/22.session/root cpuset:/sys/fs/cgroup/cpuset/user/1000.user/22.session/root memory:/sys/fs/cgroup/memory/user/1000.user/22.session/root cpu:/sys/fs/cgroup/cpu/user/1000.user/22.session/root blkio:/sys/fs/cgroup/blkio/user/1000.user/22.session/root hugetlb:/sys/fs/cgroup/hugetlb/user/1000.user/22.session/root]

whereas when I did kill -KILL <pid>, with the pid of the process running in the container, I didn't see those messages.

As noted in #39, if I kill the runc process itself, /var/run/opencontainer/containers/root/state.json remains and runc start didn't work. That's an unclean shutdown, but in case it does happen, do I just need to remove state.json or is there kernel state that I need to clean up as well?

Thanks!

[rajasec]

Removing state.json should suffice to start back the container.

[apatil]

I just checked and it does suffice to start the cotnainer. It's really nice that only one simple action is required to get up and running again after an unclean shutdown.

Putting my question another way, after any of those shutdown scenarios, will there be cgroups, namespaces, mounts, network objects or other things left around? If so, is it possible that the leak will eventually cause problems?

[crosbymichael]

runc kill should be the same semantics as doing a kill on the pid1 of the container. You really don't want to kill the runc process, only the process inside the container.

[apatil]

OK, got it. As I noted in my comment above, it looks like runc kill is different than kill on pid1 at the moment.

When the runc process does happen to get killed, it would be very helpful if either runc automatically cleans up the next time it runs, or else there's some kind of runc cleanup command that lets me do it manually.