Under "expect" I meant that Mesos expects users to set CommandInfo.arguments in a way `exec` does not error out. I'm an ESL, but I would have used "require" if we had validation in place. We don't, and I find this unfortunate. I see why one may want to set argv[0] to a value different from the command, but I'm not sure to what extent it applies to Mesos context. Moreover, the `exec` design seems a bit unfortunate to me and I'm not yet convinced we should repeat it in the Mesos API.
Since my concern is mostly a "bad address" crash if CommandInfo.arguments are empty while CommandInfo.shell is false, how about updating the command executor to address only this case: if `shell` is false and `argv.size` is 0, assign command to `argv[0]`? 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 > > > > > >
