Instances: runscript vs startscript in bootstraped containers

[Thomas Hartmann]

Hi all,

I have bootstraped a Docker image as into a Singularity sandbox.

Running the container directly worked fine, so I tried to start the
container as an instance into the background.

However, the actual supposed process in the container does not get
started and the container instance stays idle (until I connect and start
the process myself).

Thing is AFAIS, that for the instance to star, I need the process
defined in the startscript - but the bootstrapped container has it as
entrypoint only in the runscript (probably due to the original
Dockerfile definition - have to check).

So, after tweaking the container's startscript, the instance behaves as
planed - but I wonder, if there is a 'more official' way to 'start' an
instance from the runscript... (*)

Cheers and thanks,
Thomas

(*) I am aware, that this might be not a very good thing and that there
are probably good reasons to differentiate between 'starting' something
(like services) and 'running' a one-shot program ;)

[Dave Godlove]

So this is an interesting idea.  Instances are fairly new to Singularity.  Before they existed, both CMD and ENTRYPOINT in Docker speak just corresponded to a runscript in Singularity speak.  See here for the details.

http://singularity.lbl.gov/docs-docker

But now that we also have a startscript (because we have instances), it may be useful to revisit this topic and think about how that relates to Docker.  Does CMD == startscript and ENTRYPOINT == runscript?  Or should Singularity just give the user the option at buildtime to move a runscript to a startscript or vice versa?  What do others think? 

--
You received this message because you are subscribed to the Google Groups "singularity" group.
To unsubscribe from this group and stop receiving emails from it, send an email to singularity+unsubscribe@lbl.gov.

[David Trudgian]

Hi All,

Quick notes on ENTRYPOINT/CMD...

The current way that Singularity handles the ENTRYPOINT and CMD (documented in the link from the other Dave) isn’t really correct from the point of view of expected behavior / OCI compliance. In Dockerfiles ENTRYPOINT and CMD can be additive. If you have an entry point listing a command ‘/bin/echo’ then CMD would give a default argument ‘hello’. If you run the container without args you get `echo hello`. If you provide args the override CMD and not ENTRYPOINT so `exec mycontainer boo` gives `echo boo`.

There’s a plan to correct this in Singularity 3.0 - so we can align with OCI things when handling docker/OCI images. It hasn’t been corrected in 2.x as behavior changes are preferred for major version increments.

Anyway - with regard to the though of instances, I don’t see there is a mapping like CMD==startscript and ENTRYPOINT==runscript, unless it was done in a way that allows us to replicate expected behavior (from a docker/oci standpoint) when the Singularity container is run.

(There is a nice write up of ENTRYPOINT and CMD here… https://www.ctl.io/developers/blog/post/dockerfile-entrypoint-vs-cmd/)

Cheers,

Dave T

To unsubscribe from this group and stop receiving emails from it, send an email to singularity...@lbl.gov.

[Thomas Hartmann]

Hi Dave and David,

many thanks for the explanation! The write up regarding CMD & ENTRYPOINT
in Docker is really a good read - I will see to define my containers
more stringent along these lines, i.e., ensure startscript to be
somewhat more 'self-contained' compared to stuff via runscript.
But I don't have a very strong opinion on what to expect as 'orthodox
behaviour' from Singularity in this direction ;)

Cheers and thanks,
Thomas