[rfc] rkt kill

[vcaputo]

There's no way to "stop" a rkt container today, it seems a general rkt kill $SIGNUM analogous to the standard unix kill(1) command would go a long way towards providing it.

The rkt kill command could deliver the specified signal or the default SIGTERM to the top-level process representing the named pod.

It's a bit awkward with systemd in stage1 though, because systemd handles SIGTERM with the following:

   SIGTERM
      Upon receiving this signal the systemd system manager serializes
      its state, reexecutes itself and deserializes the saved state
      again. This is mostly equivalent to systemctl daemon-reexec.

which isn't what we'd expect from a bare rkt kill $pod delivering SIGTERM as the default.

This has been brought up previously: #532 (comment)

Does it make sense to have a general kill which delivers a signal to the pod's top-level process? Or should we make a less general rkt stop which employs some stage1-specific stop entrypoint to Do The Right Thing?

[blixtra]

IMHO, from a semantic point of view we should only have a stop if we have a start, analogous to the the freeze/thaw in the issues you pointed to.

[alban]

I think something specific would make it more user-friendly. For systemd-stage1, kill -37 $SYSTEMD_PID and kill -47 $SYSTEMD_PIDworks fine and would be the equivalent of rkt stop and rkt stop --force:

       SIGRTMIN+3 (kill -37)
           Halts the machine, starts the halt.target unit. This is mostly
           equivalent to systemctl start halt.target.
       SIGRTMIN+13 (kill -47)
           Immediately halts the machine.

I don't know if it worth an entrypoint with a binary just to send a signal.

[vcaputo]

well, what's appropriate for stopping lkvm? that's where the entrypoint comes in.

[jonboulle]

naive driveby, can't we kill systemd-nspawn/lkvm process and it'll Do The
Right Thing?

On Mon, Sep 28, 2015 at 3:35 PM, Vito Caputo notifications@github.com
wrote:

well, what's appropriate for stopping lkvm? that's where the entrypoint
comes in.

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

[iaguis]

By default, if --boot is used and you send SIGTERM to systemd-nspawn it will send SIGRTMIN+3 to PID 1 in the container.

I don't see any kind of similar signal handling in lkvm. There's lkvm stop though.

[jonboulle]

/cc @jellonek @ppalucki

[vcaputo]

Maybe we just send SIGTERM to the outer rkt process of the pod then, like any process manager would do. The only reasons I can see for introducing a stop stage1 entrypoint are:

1. symmetry (we have a run entrypoint)
2. if a stage1 implementation benefits from a more graceful/involved exit path, it could be stuck in the stop.

Maybe it makes sense to have a stop entrypoint, invoke it when set, and afterwards send SIGTERM all the same to the outer rkt process of the pod.

I don't like the stop entrypoint for what it implies; the wrong thing will happen when plain SIGTERM is delivered as would be by a process manager. So maybe it's a flawed idea, symmetry be damned.

[markuskobler]

So I think I have a related issue that would benefit from generic rkt kill --signal=HUP command.

I'm currently trying to port a haproxy docker container that uses haproxy-systemd-wrapper to gracefully reload its configuration after a HUP signal. Currently I cant see a good way to signal the master process started by rkt.

[yifan-gu]

Maybe we should return the pid of the stage1 now? On an oob discussion @vcaputo told me currently pid returned by rkt status is the pid of PID1 in the nspawn container(the systemd), because we need that to enter the namespace. But as now rkt enter takes the uuid of the pod, I think we don't have to show the pid of the systemd now.

[markuskobler]

Ah that would really help.

[iaguis]

#1699

[alban]

#1699 has been merged, so it returns the pid of stage1 now.

[philips]

My hunch here is to do a rkt stop and then make sure we have the right behavior wired up for each stage1. Sending a kill with an arbitrary signal won't work everywhere right now. If we do kill we would need to try and figure out what the different "rkt signals" we could send would be.

[iaguis]

My hunch here is to do a rkt stop and then make sure we have the right behavior wired up for each stage1. Sending a kill with an arbitrary signal won't work everywhere right now. If we do kill we would need to try and figure out what the different "rkt signals" we could send would be.

Started working on this https://github.com/kinvolk/rkt/commits/iaguis/rkt-stop

It sends SIGTERM to the pid of stage1 for the nspawn and fly flavors and it calls lkvm stop ${VM} for the lkvm flavor.

It seems to work but I want to do some refactorings to get rid of flavor code messiness (e.g. all the if flavor == "kvm").

[sjpotter]

for cadvisor testing this would be nice, i.e. I'm systemd-run'ing rkt to run-prepared the containers in the background and would just like to stop the uuid

[ghost]

I'd also need to signal a process running inside a Rkt container. In my case that would be coreos.com/dnsmasq, which reloads its hostsfile upon receiving SIGHUP.