It looks to be a useful feature to have. Some comments:

• naming: I would name the feature "rkt freeze" or "rkt pause". When I read the title, I thought this was about killing the containers with SIGTERM or SIGKILL because that's what "docker stop" does. Using the command name "rkt pause" would be consistent with the same command in Docker.
• The implementation sends a SIGSTOP to systemd in the container (pid mentioned in the pid file). It does not stop/pause the applications in the container. Sending a SIGSTOP to all processes in the container could cause problems if some applications use SIGSTOP/SIGCONT. Instead of using signals, the cgroup freezer can be used instead:

https://www.kernel.org/doc/Documentation/cgroups/freezer-subsystem.txt

• I'm not sure how to get the name of the cgroup for a container for the freezer. While testing, it can be found with "systemd-cgls". Maybe stage1 should generate a systemd unit file with a cgroup name specified? When implemented, the stage1 doc should be updated.

https://github.com/coreos/rocket/blob/master/Documentation/stage1-implementors-guide.md

• When a container runs several apps (e.g. launched with "rkt run example.com/app1 example.com/app2" or with future pods spec: introduce pods appc/spec#150), do we want to pause all apps at the same time or only one app?
• Should the processes created by "rkt enter" be paused too? I suggest they should not.

+1 on calling this pause. Can someone describe the use case?

There are some use cases for container checkpoint restart:
http://criu.org/Usage_scenarios

+1 on supporting pause and eventually checkpoint restore.

As for my use-case: I'm working on a project that uses containers (currently docker, hoping to move to rocket soon) to host PHP applications and unfortunately the preferred php opcode cache does not support persisting to disk. This can have a huge impact on startup time for first request. My use case involves oversubscribing host machines and shutting down idle services - currently using pause for some amount of time to ensure the processes are blocked and not using any cpu resources and then eventually stopping them completely. They're then restarted when a new request is received by the reverse proxy (somewhat similar to systemd socket activation). The ability to pause helps, the ability to do checkpoint restore would be amazing as it could save over a minute of php parsing time on some large applications on that first request after hibernation.

Any reason not to instead have a general rkt kill to send any signal to the container, defaulting to SIGTERM just like kill(1)?

@vcaputo the freezer subsystem does something different - it let's you block a process while keeping it in memory. As I said before this functionality is helping me personally on a docker powered project right now and it's a prerequisite for layering checkpoint/restore on top after the fact. Unless I'm misunderstanding?

@tizzo my comment is regarding the actual commit in the PR, @alban is clearly referring to something more elaborate like rkt freeze / rkt thaw, and that should probably move into an issue of its own.

👎 on the PR though; not fond of having a subcommand implementing just kill -SIGSTOP $cpid, but something similar in a more general rkt kill may be ok.

Ah sorry, misread - thanks.

On Tue, Feb 17, 2015 at 3:06 PM, Vito Caputo notifications@github.com
wrote:

@tizzo https://github.com/tizzo my comment is regarding the actual
commit in the PR, @alban https://github.com/alban is clearly referring
to something more elaborate like rkt freeze / rkt thaw, and that should
probably move into an issue of its own.

[image: 👎] on the PR though; not fond of having a subcommand
implementing just kill -SIGSTOP $cpid, but something similar in a more
general rkt kill may be ok.

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

chiming in with $2e-2: I agree with vcaputo/alban, the particular implementation in this PR is not quite the direction we should go but the more elaborate freeze/thaw is something worth exploring. @tizzo do you think you could capture this feature request in another issue?

@enten, what was your use case for your stop command?

#543

@enten Ping to #532 (comment)

The standard scenario : when a user explicitly wants to stop all apps from a container.
Its can be useful for the composability of Rocket. For example : I want to create REST services for manage containers. And I want a service to shutdown a specific container.

@enten sorry for the delay but I am going to close this out. I think #532 (comment) and #532 (comment) nailed some of the issues with this particular approach, but we would definitely be receptive to a more comprehensive freeze/thaw (probably via #543).