singularity
singularity copied to clipboard
Singularity unexpectedly appears to look outside containers for CMD path
Version of Singularity singularity-ce version 3.10.2-bionic singularity version 3.5.3-bionic
Describe the bug I've been experiencing odd behaviour with singularity - it doesn't appear to actually do things within my containers. I can reproduce this behaviour across multiple systems so I'm really not sure what's happening. I've tried this so many ways round and I cannot get it to work.
To Reproduce Steps to reproduce the behavior:
singularity pull library://lolcow
singularity exec lolcow_latest.sif ls
Expected behavior ls returns a view of inside the container. Instead it returns a view of the host filesystem at the current directory In the case of my actual work (which unfortunately I can't share), the following happens:
ubuntu@x:~/app$ ./container.sif
FATAL: stat /home/ubuntu/app/.env/bin/command: no such file or directory
n.b. that home/ubuntu/app
is the host directory from which I am executing the commands. .env/bin/myapp is the container entrypoint, which should execute successfully inside the container filesystem. The def file looks like:
Bootstrap: docker
From: python:3.10-slim
%files
myapp temp
setup.py
%post
useradd -ms /bin/bash myuser
su - myuser
mkdir myapp
mv /temp myapp/myapp
mv /setup.py myapp/setup.py
python3.10 -m venv .env
. .env/bin/activate && pip install ./myapp
%runscript
.env/bin/myapp
The equivalent definition file works in docker, but not if I convert a docker image to a singularity one. I've tried this all sorts of ways round and am baffled.
OS / Linux Distribution Which Linux distribution are you using?
$ cat /etc/os-release
Installation Method Various
Additional context Anything else which might be relevant. E.g. if the bug only occurs on a specific filesystem, or kernel version etc.
Hi @blex-max - this is normal behaviour for Singularity. It automatically mounts the CWD into the container and begins there when entering the container. Your runscript .env/bin/app
is going to try to execute .env/bin/app
relative to that CWD.
Singularity was designed to be easier than Docker for users running applications interactively on a system, against data on the host. This is the reason for this behaviour - to make containers work more like an application running on the host, by default.
Note also that by default singularity always runs as the user inside the container that it is outside. It won't honor a Docker USER
command, for example, so adding a user in the container and installing things for that user isn't recommended.
I'd suggest taking a look at this guide for the differences between Singularity and Docker, and checking out the Google Group or Slack workspace if you have questions. Note the guide mentions flags that can be used to get behavior that is similar to Docker.
https://docs.sylabs.io/guides/latest/user-guide/singularity_and_docker.html#differences-and-limitations-vs-docker
Ah, thank you very much! Apologies for my bug report. --cleanenv and --contain do what I need. Is there perhaps a way to specify those at build? I've since realised that another part of the problem was that Singularity appears to by default perform the operations specified before %runscript in a different location where runscript is run. my app was installed at fs root and I have managed to get things working with (in addition to the flags):
%runscript
cd /
.env/bin/myapp "$@"
This was a bit unexpected but fine now I realise it is the case. Any problems in future I'll be joining the slack/google group, thanks!