Connor, this is also fine and improves current behaviour.
On Sat, Apr 9, 2016 at 10:52 PM, <[email protected]> wrote: > Hi Alex, inline. > > > On Apr 9, 2016, at 12:00, Alex Rukletsov <[email protected]> wrote: > > > > if `shell` is false and `argv.size` is > > 0, assign command to `argv[0]`? > > Instead of trying to fix the TaskInfo on behalf of the framework, maybe it > would be more transparent to preemptively fail the task with TASK_ERROR in > this case? > > > On Sat, Apr 9, 2016 at 2:59 AM, Benjamin Mahler <[email protected]> > wrote: > > > >>> > >>> Mesos expects the first argument to be the same > >>> as the command itself [1] > >> > >> > >> To be precise, what does "expect" mean here? Do we actually have code in > >> mesos with this expectation? Or are you just saying that we require > >> CommandInfo.arguments to map directly to exec's 'args'? > >> > >> Have you considered why exec has this API? It looks like there are some > use > >> cases for not just using the filename as argv[0]? > >> > >> http://pubs.opengroup.org/onlinepubs/9699919799/functions/exec.html > (see > >> Rationale) > >> > >>> The requirement on a Strictly Conforming POSIX Application also states > >>> that the value passed as the first argument be a filename string > >> associated > >>> with the process being started. Although some existing applications > pass > >> a > >>> pathname rather than a filename string in some circumstances, a > filename > >>> string is more generally useful, since the common usage of argv[0] is > in > >>> printing diagnostics. In some cases the filename passed is not the > actual > >>> filename of the file; for example, many implementations of the login > >>> utility use a convention of prefixing a <hyphen> ( '-' ) to the actual > >>> filename, which indicates to the command interpreter being invoked that > >> it > >>> is a "login shell". > >> > >> > >>> On Sat, Apr 2, 2016 at 7:14 AM, Guangya Liu <[email protected]> > wrote: > >>> > >>> +1 on using docker mode, this can help the framework developer. > >>> > >>> Setting the command twice can sometimes make people confused. When I > was > >>> working for the patch https://reviews.apache.org/r/44441/ , I was > also a > >>> bit confused before go through the code in agent part. > >>> > >>> > >>> > >>>> On Sat, Apr 2, 2016 at 1:17 AM, haosdent <[email protected]> wrote: > >>>> > >>>> +1 For follow Docker behaviour, it is inconvenient to write the > command > >>>> twice. > >>>> > >>>> On Fri, Apr 1, 2016 at 10:12 PM, Alex Rukletsov <[email protected]> > >>>> wrote: > >>>> > >>>>> When launching a command task without wrapping it in `/bin/sh -c` > >> (i.e. > >>>>> CommandInfo.shell=false), Mesos expects the first argument to be the > >>> same > >>>>> as the command itself [1]. Though this is similar to how UNIX exec* > >>> calls > >>>>> operate, it can be unclear to a user. Moreover, we do not validate > >> this > >>>> on > >>>>> the master side, but rather let the command executor crash with a > >> "bad > >>>>> address" error. Docker, for example, requires the command only once > >> in > >>>>> their entrypoint specification [2]. > >>>>> > >>>>> My suggestion is to change the command executor so that it ensures > >> that > >>>> the > >>>>> first argument is always the command itself. > >>>>> > >>>>> Alternatively, if we prefer to keep the current behaviour, I would > >>>> propose > >>>>> to adjust the documentation to be more explicit and introduce a > >>>> validation > >>>>> check on the master. > >>>>> > >>>>> [1] Example snippet in C++ > >>>>> > >>>>> commandInfo->set_value(command); > >>>>> > >>>>> commandInfo->add_arguments()->assign(command); > >>>>> > >>>>> > >>>>> [2] https://docs.docker.com/engine/reference/builder/#entrypoint > >>>> > >>>> > >>>> > >>>> -- > >>>> Best Regards, > >>>> Haosdent Huang > >> >
