behaviour on singularity run if no runscript?

Grigory Shamov

unread,

Oct 31, 2016, 4:17:30 PM10/31/16

to singu...@lbl.gov

Hi All,

What should be the default behaviour of Singularity if some of the
%runscript section is not provided by the .def file?

Right now, in 2.2, "singularity test" gives ³No test code provided in this
container² and stops.
"singularity exec² w/o the command does nothing. And stops.

But ³singularity run² does say ³No Singularity runscript found, executing
/bin/sh² and gives the interactive shell.

Would it be perhaps more natural for ³singularity run² to do nothing and
stop as ³exec" and ³test" do? I am thinking of the case of a user having
"singularity run" on a container that meant to be used with "singularity
exec² : it perhaps should be safer for such a job to fail immediately
rather than to sit there and wait in shell, no?

(Or am I missing some config there that exists and does set such default
behaviour?)

--
Grigory Shamov

Westgrid/ComputeCanada Site Lead
University of Manitoba
E2-588 EITC Building,
(204) 474-9625

vanessa s

unread,

Oct 31, 2016, 4:31:37 PM10/31/16

to singu...@lbl.gov

Quick question - wouldn't code for singularity testing need to go in %test?

imho - the %runscript section shouldn't be required, and given that it's not required, I think that the default behavior of running /bin/sh is a reasonable thing to do. Why? A few reasons:

- most new users are going to follow the workflow of create --> run, and they probably won't know to make or specify a runscript. What they really want to do is get into the container, so if they do singularity run and nothing happens, it's confusing. The reason (I think) that the message is there is to prompt them to thing "huh, there is this thing called a runscript, and it wasn't found, does that mean I can change that?"

- Docker has similar subtle differences between exec and run. Exec is more like "shove this command to this container, do it, and then back to my command window." That can be modified with something like:

docker exec -it [containerid] bash

which means "run and interactive terminal with bash command" (which will not return to the user command line until they exit) but it's a little farther away from the traditional exec command. Run, on the other hand, is what you would expect - you want to think of your container like an executable and run it, and it does whatever it's supposed to do. This is different from exec because exec the executor (**Halloween screens**) determines the command run.

I hope that the discussion above cleared up the confusion that (I think) you might have between run/exec, which I infer when you say "a container meant to be used with singularity exec' - containers are not "meant" to be used with exec, they are intended (for users) to be run with singularity run --> runscript, and exec is more sending a specific command to the container. If you want to provide explicit instructions to the user for using exec, this would work, but I would suggest instead writing a runscript that takes input arguments to handle the commands you have in mind, because running the container as an executable (.container.img) will also trigger the runscript.

--
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.

--

Vanessa Villamia Sochat
Stanford University '16

(603) 321-0676

Grigory Shamov

unread,

Oct 31, 2016, 5:27:31 PM10/31/16

to singu...@lbl.gov

Hi Vanessa,

Yes; I guess I wasn’t precise. The question is , why (missing) %runscript is different from (missing) %test .

Workflow: ultimate HPC workflow is running batch jobs. Thats what HPC users should really want to do. Or at least thats what we force them to do on HPC systems. In HPC environment interactive work is not something that majority if the users would do in production. They do run batch jobs with RM’s like Torque or SLURM or LSF.

Singularity is great for packing the compute payload to make it mobile for HPC environment; As an HPC analyst, I would be happy to pack everything the users think of running, for them. Or to run containers that come from elsewhere, provided they have correct setup for us (correct mount points for home and global scratch and local scratch; btw correct UNIX groups for software access is something also interesting).

Confusing – not really, if missing %runscript emits a clear message, similar to missing %test, it is not confusing.

I am not a docker expert; from my brief glance docker has an explicit command line switch “-it” or something, to make things interactive. While for "singularity run", change from batch to interactive just happens if there is no %runscript. If there is no %test, why not to go interactive then?

--

Grigory Shamov

Westgrid/ComputeCanada Site Lead

University of Manitoba

E2-588 EITC Building,

(204) 474-9625

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

Gregory M. Kurtzer

unread,

Oct 31, 2016, 5:36:45 PM10/31/16

to singularity

Hi Grigory,

I apologize, I'm not perfectly clear on what you are asking.

Are you asking for a feature change such that no %runscript defined will give the same result as no %test defined? Or are you just asking why are they different?

If the latter, it is because (at least in my head) it seemed reasonable for the command "singularity run container.img" or more specifically "./container.img" to land at a shell if no runscript was given. That way executing a container directly will just give you a shell if no runscript is given. Obviously that doesn't apply to %test.

Greg

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

--

Vanessa Villamia Sochat
Stanford University '16

(603) 321-0676

--
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.

--
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.

--

Gregory M. Kurtzer

HPC Systems Architect and Technology Developer

Lawrence Berkeley National Laboratory HPCS
University of California Berkeley Research IT
Singularity Linux Containers (http://singularity.lbl.gov/)