I think you guys are kindda on the right track. But you are trying to impose some un-needed restrictions in regards to CMD vs ENTRYPOINT usage.
To docker, the final combination of ENTRYPOINT + CMD is all that matters. So long as the first arg is /init. Then any remaining args should be shifted and used to determine what program is being run on supervision. So basically all the user has to care about (to get process supervision) is to pre-pend "/init" as the first argument, before argv[0] (the command to run) and any optional subsequent args. If there is no arguments after "/init". Then it's multi-manages process. And just conventional ways (inspect config directories for each services). You CANNOT enforce specific ENTRYPOINT + CMD usages amongst docker users. It will never work because too many people use docker in too many different ways. And it does not matter from a technical perspective for the solution I have been quietly thinking of (but not had an opportunity to share yet). It's best to think of ENTRYPOINT (in conventional docker learning before throwing in any /init system) and being "the interpreter" such as the "/bin/sh -c" bit that sets up the environment. Like the shebang line. Or could be the python interpreter instead etc. It's best to understand CMD as being the docker image's user presentation of its exposed "command interface". So for example if you ran docker inside of docker, it's overridable CMD part would be the docker subcommands such as 'run' 'stop' etc. And then users can understand that "docker run docker <cmd> <args>" Is all they need to care about from a user perpective. --help usage of the docker image and so on. But technically, /init should only ever receive and argv[] array which is the combined ENTRYPOINT + CMD appended after it (whether the user has overridden entry point or has no entry point set is entirely their business. And inside of /init it cannot know such things anyway. My suggestion: * /init is launched by docker as the first argument. * init checks for "$@". If there are any arguments: * create (from a simple template) a s6 run script * run script launches $1 (first arg) as the command to run * run script template is written with remaining args to $1 * proceed normally (inspect the s6 config directory as usual!) * as there should be no breakage of all existing functionality * Providing there is no VOLUME sat ontop of the /etc/s6 config directory * Then the run script is temporary - it will only last while the container is running. * So won't be there anymore to cleanup on and future 'docker run' invokations with different arguments. The main thing I'm concerned about is about preserving proper shell quoting, because sometimes args can be like --flag='some thing'. It may be one simple way to get proper quoting (in conventional shells like bash) is to use 'set -x' to echo out the line, as the output is ensured by the interpreter to be re-executable. Although even if that takes care of the quotes, it would still not be good to have accidental variable expansion, interpretation of $ ! etc. Maybe I'm thinking a bit too far ahead. But we already know that Gorka's '/init' script is written in bash. Sorry for coming at it from a completely different angle! :) On Thu, Feb 26, 2015 at 5:03 PM, John Regan <j...@jrjrtech.com> wrote: > > >> I think you're better off with: >> >> * Case 1 : docker run --entrypoint="" image commandline >>(with or without -ti depending on whether you need an interactive >>terminal) >> * Case 2 : docker run image >> * Case 3: docker run image commandline >>(with or without -ti depending on whether you need an interactive >>terminal) >> >> docker run --entrypoint="" -ti image /bin/sh >>would start a shell without the supervision tree running >> >> docker run -ti image /bin/sh >>would start a shell with the supervision tree up. >> > > After reading your reasoning, I agree 100% - let -ti drive whether it's > interactive, and --entrypoint drive whether there's a supervision tree. > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity.