config: StopSignal support

[cyphar]

Recently in the image-spec (opencontainers/image-spec#544) support for StopSignal was added. As part of opencontainers/image-spec#492 I've been working on trying to make the conversion from Image -> runtime configuration lossless (in one direction at least).

However, currently (as far as I can tell) there isn't a proper way of specifying what signal the runtime should send to the init process. While we define a kill operation, we should probably provide some default which is stored in the config.json to be able to implement this aspect of the conversion?

[runcom]

My understanding was that each runtime (for any valid reason) has a default signal which varies on platform for instance so it's in charge of defining so and the image config alone (which is platform specific) is the only one to specify the kill signal. (did I miss something?)

[cyphar]

@runcom While that is mostly right (though the kill operation is defined to also have a <signal> argument which is provided by the user), the point of this is that conversion from the Image configuration (which is generic) to config.json (which is platform-specific) is not possible for StopSignal currently because the runtime specification doesn't provide the necessary options.

I mean, this could just be implemented as an annotation but then it's of less use for users (the system then has to follow the annotation which is the same as adding a field to process).

[dqminh]

I think being able to set stop-signal as part of process config makes sense. Not every application is intended to be stop with the default sigterm signal.

[wking]

On Mon, Feb 27, 2017 at 02:10:24AM -0800, Aleksa Sarai wrote: I mean, this _could_ just be implemented as an annotation but then it's of less use for users (the system then has to follow the annotation which is the same as adding a field to `process`).

If we represent StopSignal in the config JSON, *somebody* is going to have to look it up as part of the ‘kill’ operation (assuming the user hasn't explicitly specified a signal when invoking ‘kill’). Once you have that (whether it's part of ‘kill’ itself or some helper code), I don't think it matters whether the default-term-signal field goes in ‘process’ or ‘annotations’. My personal preference would be to put it in ‘annotations’, because it's not part of creating the container process. But it doesn't really matter where it lives. And my personal preference would be to document the location in opencontainers/image-spec#492 and handle default-term-signal lookup in external tooling. There's no need to talk about it in runtime-spec or complicate the ‘kill’ operation. Folks who want to wrap their runtime in a more convenient UI that performs the default-term-signal lookup when necessary could do that easily on their own, or a runtime-tools helper could do this, etc. etc. But again, it's not a big deal if runtime-spec maintainers decide that this lookup is something all ‘kill’ implementations need to implement internally.

[crosbymichael]

I think it makes sense for the image spec but i'm unsure about having it in the runtime spec. The runtime is mostly imperative with little defaults. It just does what you tell it to do. We only have a default kill signal as a usability thing but if you don't want to use the default then tell it exactly what you want.

Any kill operations inside the runtime always uses SIGKILL and SIGTERM is only the default on the cli command.

Currently the runtime spec has fields for how to create the container and process and nothing about how to manage it after the creation. Adding this inside the spec changes what and I think it would be best to just leave this to the caller and keep the spec simple and focused on the create of the container and process.

[cyphar]

Alright. I'll make it map to an annotation then.