Clarify process.terminal semantics.

[cyphar]

Currently we just say the following:

• terminal (bool, optional) specifies whether you want a terminal attached to that process. Defaults to false.

While I understand that the spec should be vague on what a "terminal" is, I'm having trouble understanding what runC should do with this flag (maybe @crosbymichael can help clarify this). From my understanding (in the Linux parlance) it means that you don't create a new pty for the container. However, it's not clear if "don't create a new pty" means that we should dup(2) /dev/null over all of the process's stdio file descriptors -- or if it's something more subtle.

I'm tagging this as 1.0 because I feel like it's one of the smaller issues that we probably should clarify a bit (or at least agree on whether or not it even needs clarification).

[wking]

On Wed, Jun 08, 2016 at 06:24:07AM -0700, Aleksa Sarai wrote:

While I understand that the spec should be vague on what a
"terminal" is, I'm having trouble understanding what runC should do
with this flag…

I agree that the current wording is unclear 1. And I see no reason
to be vague about what “terminal” is, unless someone can explain how
this setting is useful for systems that don't have a psuedoterminal
analog.

 Subject: More detail for process.terminal?
 Date: Thu, 14 Jan 2016 14:44:08 -0800
 Message-ID: <20160114224408.GM6362@odin.tremily.us>

[crosbymichael]

While we are talking about this, should this be an option in the spec or just something that is dynamic at runtime if the user passes a --tty and/or --console flag?

[wking]

On Fri, Jun 10, 2016 at 10:55:18AM -0700, Michael Crosby wrote:

While we are talking about this, should this be an option in the
spec or just something that is dynamic at runtime if the user passes
a --tty and/or --console flag?

For third-party config authors, that's “does this matter inside the
container?”. I can't think of a reason why it would, so I'm fine
punting the option from the spec. I would like to see a command-line
API 1 or some such so runtime-callers had a standardized way to
enable the functionality (which I think we still want to require
runtimes to support so folks can build web frontends for terminal
sessions and such). And it's probably worth getting feedback on the
migration from anyone who's actually using the feature now (start a
thread on dev@ to raise awareness? Ping folks in next week's
meeting?).

 Subject: Specifying the runtime's command-line interface
 Date: Tue, 18 Aug 2015 10:52:55 -0700
 Message-ID: <20150818175255.GV21585@odin.tremily.us>

[wking]

Fixed by #518? Or is this still blocking on what the property means for other OSes? Or something else?

[crosbymichael]

After our discussion on the OCI call last Wednesday, we decided that the field should be kept as a declaration of the process of the container requires a terminal to be used. Also the changes referenced to runc have been resolved with the console PRs.

I think this can be closed as resolved now, if I'm wrong please re-open.