[jira] [Commented] (MESOS-8978) Command executor calling setsid breaks the tty support.

["Kevin Klues (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/MESOS-8978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16635220#comment-16635220 ] 

Kevin Klues commented on MESOS-8978:
------------------------------------

{noformat}
commit 716bb9f65974e4479d9ad794c145aa8293cea203
Author: Kevin Klues klueska@gmail.com
Date:   Tue Oct 2 11:40:52 2018 +0200


Added the ability to launch tasks with a TTY attached to mesos-execute.

Review: https://reviews.apache.org/r/68724/
{noformat}
{noformat}
commit 12b6ab6bdabfc37f73439ea55ef0a7f0ee680983
Author: Kevin Klues klueska@gmail.com
Date:   Tue Oct 2 11:41:12 2018 +0200


Removed call to 'setsid()' in command executor if TTY attached.

Previously, we would unconditionally call 'setsid()' in the command
executor whenever we launched a process. This causes the process it
launches to start a new session and NOT inherit the controlling TTY
from it's parent. This obviously causes problems, if the goal of
attaching a TTY to a task is so that we can actually give it control
of that TTY while it is executing.

Interestingly, even if process does not control its TTY, it can still
read and write from the file descriptors associated with it (it just
can't receive any signals associated with it, such as SIGWINCH,
SIGHUP, etc.). This is why things "appeared" to mostly work until this
point because stdin/stdout/stderr were all being redirected properly
to it.

Where we saw problems was with trying to 'attach' to an already
running process launched via the command executor using the
ATTACH_NESTED_CONTAINER_INPUT/OUTPUT calls. If you ran something like
'bash', you would not be able to do job control, and you could not
resize the screen properly when running things like 'vim'.

This commit fixes this issue by checking to see if a TTY has been
attached to a task launched by the command executor, and skipping the
'setsid()' call when forking it. We considered a number of alternative
approaches, but finally settled on this one since it was the least
invasive. I.e. only tasks launched with a TTY (which is a failry new
concept in Mesos) will be affected by this change; the semantics of
all traditional tasks launched via the command executor will go
unchanged.

Note: this problem does not exists for the default executor because
the agent does the job of launching all containers, and there is no
executor sitting between the containerizer and the actual process of a
task intervening to call an extra 'setsid()'. This is why containers
launched via LAUNCH_NESTED_CONTAINER_SESSION have always worked as
expected.

Review: https://reviews.apache.org/r/68810/
{noformat}

> Command executor calling setsid breaks the tty support.
> -------------------------------------------------------
>
>                 Key: MESOS-8978
>                 URL: https://issues.apache.org/jira/browse/MESOS-8978
>             Project: Mesos
>          Issue Type: Bug
>    Affects Versions: 1.4.1, 1.5.1, 1.6.0
>            Reporter: Jie Yu
>            Assignee: Kevin Klues
>            Priority: Major
>             Fix For: 1.5.2, 1.6.2, 1.7.1, 1.8.0
>
>
> I was playing with [msh|https://github.com/mesos/mesos-go/blob/master/api/v1/cmd/msh/msh.go] (one example from [mesos-go|https://github.com/mesos/mesos-go]), which allows you to launch an interactive shell in the Mesos cluster. It works by launching a container with tty enabled, and then [attach to the container input|https://github.com/apache/mesos/blob/master/include/mesos/v1/agent/agent.proto#L191-L201] using the agent operator API.
> However, I got the following error when doing the following:
> {noformat}
> Jies-MacBook-Pro:mesos-go jie$ ./msh -master 127.0.0.1:5050 -tty -interactive -- /bin/sh -i
> ...
> 2018/06/05 11:51:35 original window size is 156 x 45
> sh: cannot set terminal process group (-1): Inappropriate ioctl for device
> sh: no job control in this shell
> {noformat}
> If I use `-pod`, the problem goes away. This only happens if command executor is used.
> A few research suggested that this issue is related to `setsid` (see this [thread|https://github.com/Yelp/dumb-init/issues/51#issuecomment-227792216]). Looks like we did an extra `[setsid|https://github.com/apache/mesos/blob/1.6.x/src/launcher/executor.cpp#L512]` in the command executor.
> The setsid() system call to create a new process group detaches the spawned process from a controlling tty. Therefore programs like bash complain, that they can't use job control. Re-attaching the controlling tty won't work, because the tty is still in use as a controlling tty for the command executor process.
> There are two possible solutions:
> 1) Get rid of setsid in command executor
> 2) Detach and re-attach the controlling TTY as suggested in https://github.com/Yelp/dumb-init/issues/51#issuecomment-227792216



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)