-
Notifications
You must be signed in to change notification settings - Fork 676
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Stop signal #541
Comments
On Sun, Jan 29, 2017 at 04:23:06AM -0800, Antonio Murdaca wrote:
Who is going to define the stop signal for a container? Is this an
image thing or a runtime thing?
I think it's a runtime thing, since it's sent from the runtime to the
container process. Why would it be an image thing?
And I've tried to clear up some of the currently-ambiguous spec
wording [1] in opencontainers/runtime-spec#513 by requiring POSIX
signals for platforms that support them [2].
[1]: /~https://github.com/opencontainers/runtime-spec/blob/v1.0.0-rc3/runtime.md#kill
[2]: /~https://github.com/opencontainers/runtime-spec/pull/513/files#diff-0c1e5a5baa5649945697a530e09acbf5R194
|
In the Docker scherma for the config, it's an image thing. Hence this question. |
And right now, it's both missing in image and runtime under OCI? Or am I blind? |
On Sun, Jan 29, 2017 at 03:18:49PM -0800, Antonio Murdaca wrote:
And right now, it's both missing in image and runtime under OCI? Or
am I blind?
It's not in the image spec:
image-spec$ git grep -i signal v1.0.0-rc3
…no hits…
The runtime spec currently has very vague “MUST send the specified
signal” [1]. The opencontainers/runtime-spec#513 language I linked
earlier is:
* *`--signal <SIGNAL>`* The signal to send (defaults to `TERM`).
The runtime MUST support `TERM` and `KILL` signals with [the POSIX
semantics][posix-signals]. The runtime MAY support additional
signal names. On platforms that support [POSIX
signals][posix-signals], the runtime MUST implement this command
using POSIX signals. On platforms that do not support POSIX
signals, the runtime MAY implement this command with alternative
technology as long as `TERM` and `KILL` retain their POSIX
semantics. Runtime authors on non-POSIX platforms SHOULD submit
documentation for their TERM implementation to this
specificiation, so runtime callers can configure the container
process to gracefully handle the signals.
Which seems sufficient to me. If the image authors have an opinion on
which signal their container process is looking for, I recommend
covering that in a config annotation:
"org.opencontainers.signal.stop": "RTMIN+3"
that would get copied over to the runtime config (once #492 lands) and
the runtime caller could look that up and pick the appropriate
phrasing for ‘kill’ (although as opencontainers/runtime-spec#513
stands, there's no requirement to support RTMIN+3).
[1]: /~https://github.com/opencontainers/runtime-spec/blob/v1.0.0-rc3/runtime.md#kill
|
This should have been picked up from docker config: /~https://github.com/docker/docker/blob/master/api/types/container/config.go#L59. Feel free to PR the addition. |
But that is "container config" in docker, is that still OK to move that field in config? I'm making a pr as we speak though. |
Nevermind I see it's in the image config. |
@runcom I didn't see it in the OCI specification. Is it there? |
Nope, I'll add it, sorry for the confusion. |
Who is going to define the stop signal for a container? Is this an image thing or a runtime thing?
The text was updated successfully, but these errors were encountered: