singularity icon indicating copy to clipboard operation
singularity copied to clipboard

Singularity unexpectedly appears to look outside containers for CMD path

Open blex-max opened this issue 2 years ago • 2 comments

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.

blex-max avatar Sep 30 '22 17:09 blex-max

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

dtrudg avatar Sep 30 '22 21:09 dtrudg

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!

blex-max avatar Sep 30 '22 21:09 blex-max