linux: specify a state pid/filelock for lifecycle

[philips]

No description provided.

[crosbymichael]

Many of the actions that can be performed after a container is started is done by other processes than the initial runtime. In order to synchronize these processes that could modify the state of the container we need some type of cross process locking.

[LK4D4]

Isn't this hooks problem?

[crosbymichael]

not hooks. This is for when we do checkpoint/restore, updates, or exec. All these actions are done by external processes.

[wking]

On Wed, Jul 01, 2015 at 09:40:09AM -0700, Michael Crosby wrote:

This is for when we do checkpoint/restore, updates, or exec. All
these actions are done by external processes.

With the minimal-state approach that's close to landing via #87, I
don't think we'll need any locking on the state file. Things like
“are we frozen?” will be decided by direct syscalls (e.g. each client
will read /sys/fs/cgroup/freezer/…/freezer.state like runC is doing
with opencontainers/runc#218). The state-spec version, container ID,
and application PID (and maybe some sort of root path) seem like
attributes that will be stable throughout the life of an application.

If we split container and application manipulation into their own
commands 1 the application PID might be more fluxy. We can revisit
locking if/when that happens, but until then I don't think we need it.

[crosbymichael]

In the f2f we discussed the need for state and determined that we will spec out a container action for getting the state of a container but not have a file based api for this so this is no longer needed at the state level and turns into an implementation detail for runtimes.