Why doesn't singularity bind the `/run/user/<ID>` and `/etc/machine-id` paths by default? about singularity HOT 2 CLOSED

Hi. The answers here are that we don't perform these binds & env var handling by default for simplicity, because the 'correct' behavior is ill-defined, or varies between workflows, and because running desktop applications under Singularity is relatively rare.

If we pass /run/user/xxx into the container then we are mixing aspects of the user's session on the host with the container. If you are running a graphical application from a container, but within a desktop environment running on the host, then you want tight integration and access to dbus / pulseaudio / pipewire etc. through the sockets under /run/user/xxx might be appropriate. If you are trying to run tools in a container for greater isolation / compatibility across very different host/container OS versions then it is not. Singularity is most commonly used to execute batch and command line workflows, so we avoid the potential issues of mounting /run/user/xxx by default.

With regard to /etc/machine-id there is no complete consensus on what a container runtime should do. See e.g. https://wiki.debian.org/MachineId . However, the discussion / PR for a mount that has been used in Charliecloud seems like it'd be appropriate: hpc/charliecloud#1050

If you want to mount /etc/machine-id by default, you can add it to the bind path section in the singularity.conf configuration file.

The SESSION_MANAGER env var is passed through, as Singularity's default is to pass through almost all host environment. Again, it's not always clear if things should be unset for different workflows. The SESSION_MANAGER often goes hand-in-hand with various XDG_ environment variables which are set when running under an interactive session on the host. These can be inappropriate in a container at times, but at other times their presence results in behavior that is expected (e.g. custom XDG_CONFIG_DIR locations).

One thing you can do, is set the runscript in your container definition to unset SESSION_MANGER before it runs code, something like...

%runscript
    unset SESSION_MANAGER
    code $@

Would then likely allow a singularity run to work as expected.

from singularity.

@dtrudg Thanks a lot for the extensive answer! I agree with you that the current behaviour makes sense when because running desktop applications under Singularity is relatively rare. I will close this issue since it is easy to work around these issues using the recipe file.

from singularity.