How to start a script with parameters? about s6-overlay

[sameersbn]

@gzoller I had a similar requirement, I ended up creating an wrapper for the /init script with the following content

#!/bin/bash
if [ "${1:0:1}" = '-' ]; then
  export EXTRA_OPTIONS="$@"
  set --
fi
exec /init "$@"

The script exports a variable named EXTRA_OPTIONS with all user specified command line options, removes all the args from the command line and launches the /init script of s6-overlay

Now in your services run script you can use the EXTRA_OPTIONS variable. eg.

#!/usr/bin/with-contenv bash
set -e

exec /usr/bin/mydaemon  ${EXTRA_OPTIONS:+"$EXTRA_OPTIONS"}

P.S. I am not aware if s6-overlay has any built-in option for this.

[gzoller]

I may have discovered something... If you pass other commands to /init on the command line they seem to go right through to execution. So as long as my derived Dockers always set an ENDPOINT [/init, whatever] then it may work. (At least it worked in the application I tried.) I'll have a look at the wrapper script idea too, just in case I'm misusing /init in this way.

I don't mind much if derived dockers have to follow a convention of running /init, because that's pretty generic. I just don't want them having to know about or start a bunch of specific services.

[sameersbn]

@gzoller that is true. any command specified to /init will get executed in addition to the services you may have configured. This is mostly useful for debugging, for example you can launch bash and debug stuff. Another neat feature of s6 is that it will reap zombie processes created by commands launched in this manner.

Note that when the command exits, the container exits as well.

[jprjr]

@gzoller yep - that's one of the features of the s6-overlay, it helps for those some reasons @sameersbn mentioned. The overall idea is, even with the s6-overlay setup (so downloaded and ENTRYPOINT configured), your images should still generally behave the same as the default images, up until you start adding services.

@gzoller I'd also recommend just using an environment variable to store your arguments and referencing it in your run script. So the user would run something like:

docker run -e MY_DAEMON_ARGS="-f /some/file -p -i ..." myimage

Then in your run script:

#!/usr/bin/with-contenv sh

exec /usr/bin/my-daemon $MY_DAEMON_ARGS

@sameersbn's wrapper script is a pretty good idea, though!

[glerchundi]

@gzoller I'm with @jprjr, use environment variables to customize your daemon behaviour, IMO, it's the most configurable way of handling parameters. I usually do and it works pretty well for all kind of situations.

[glerchundi]

@gzoller can we close this?

[gzoller]

Yes please. Responses were very helpful :-)

Sent from my iPhone

On Dec 3, 2015, at 4:56 AM, Gorka Lerchundi Osa [email protected] wrote:

@gzoller can we close this?

—
Reply to this email directly or view it on GitHub.