Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Should init script purge EASYBUILD_* environment variables? #58

Open
casparvl opened this issue Jan 7, 2021 · 3 comments
Open

Should init script purge EASYBUILD_* environment variables? #58

casparvl opened this issue Jan 7, 2021 · 3 comments

Comments

@casparvl
Copy link
Collaborator

casparvl commented Jan 7, 2021

Issue

I ran into this error when running from the EESSI container:

Singularity> source /cvmfs/pilot.eessi-hpc.org/2020.12/init/bash
[EESSI pilot 2020.12] $ module load EasyBuild
[EESSI pilot 2020.12] $ eb -S ReFrame
ERROR: Failed to parse configuration options: 'parseconfigfiles: configfile /sw/noarch/RedHatEnterpriseServer7/2020//software/eb/4.3.2/etc/config.cfg not found.'

Whoops, that's because our host system has EASYBUILD_CONFIGFILES set up.

How should we go about this? Should the init script unset any EASYBUILD_* variables?

@boegel
Copy link
Contributor

boegel commented Jan 7, 2021

This is a tough one, and my gut feeling says no.

You could ask the same question about other environment variables, like $MODULEPATH, $PATH, $PYTHONPATH, etc.

The purpose of the EESSI init script is not to drop you in a clean environment, but just make the necessary changes to make the software provided by EESSI accessible.

@casparvl
Copy link
Collaborator Author

casparvl commented Jan 8, 2021

I agree with that, it shouldn't be the init script. In fact, if you were running this stuff natively, it wouldn't even lead to problems: I'd get the EasyBuild installation from EESSI, but with our local configuration. That's kind of expected.

Thinking about it more, I guess the thing that felt unintuitive is the fact that the behaviour of the container is affected by these environment variables. In my mind, containers should ideally run the same, where-ever you deploy them. Also, your same argument doesn't (fully) apply there: the container has it's own $PATH, $LD_LIBRARY_PATH etc. Other variables like MODULEPATH and PYTHONPATH are inherited from the host.

Then again, maybe I just have unrealistic expectations of containers =) I don't know, maybe someone with more experience with containers should answer the question whether it is possible (or sensible) for a container to clean the host's environment variables upon container startup.

@boegel
Copy link
Contributor

boegel commented Jan 8, 2021

You can use --cleanenv with singularity shell to avoid environment variables leaking into the container, just like you can use an alternate home directory using something like --home /tmp/$USER/home_for_container

TopRichard pushed a commit to TopRichard/software-layer that referenced this issue Mar 23, 2023
pull in fixes from EESSI/software-layer PR238 and PR239
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants