Interactive app environment in 1.7

I should add that we do have a workaround for that, to add this to the template/
if [ -z “$LMOD_VERSION” ]; then
source /etc/profile.d/

You should use script_wrapper or header in your cluster config instead of editing the template scripts (script wrapper needs the %s because it wraps the script and you can have things above or below it).

          header: "#!/bin/bash"
          script_wrapper: |
            if [ -z "$LMOD_VERSION" ]; then
              source /etc/profile.d/
          # same result as above
          header: |
            if [ -z "$LMOD_VERSION" ]; then
              source /etc/profile.d/

As to the difference between 6 and 7, I can’t say off the top of my head why they’d be different.

1 Like

Thanks Jeff, I did not think about the cluster configs.

Actually, @mcuma I can think of what’s different now, especially as it relates to environment variables. We added something to copy_environment for all the schedulers.

In, say, SLURM it’s --export. Do you set and or use job_environment map? (I found through some utah docs that seem to indicate you use SLURM).

The behaviour now is, if you don’t use job_environment, it won’t use the --export flag - which is what it did in 1.6.

If you do use job_environment then it’ll do --export=NONE,FOO,BAR if you don’t use copy_environment and --export=ALL,FOO,BAR if you do set copy_environment to true (I know that phrase has alot of ifs in it and may be convoluted).

This is the only thing I can think of. The sessions could not start as a non-user, OOD submits the job through slurm as the UID of the given user (unless you have some wrapper script in front of srun).

Hi Jeff,

I think you may be on the right track since the environment seems to be passed, but, the Lmod “module” command is an alias which probably does not pass. Though, the job should be opening a new terminal on the compute node and source the Lmod, which is what the standard SLURM job does. And there the alias is functional. So, it’s still looking like the /etc/profile.d/… part is not being sourced.

I don’t think we do anything with the job environment, and the default should be --export=ALL

Is there any documentation on the job_environment?


In updating from 1.6 to 1.7, I had to add sourcing the module environment setup .sh script to script_wrapper.

Can we add this to the Docs somewhere. In the release notes maybe? This burned me as well


:frowning_face: Well there’s clearly something awry here. Looking over the code again, the default SLURM behavior for job environments should be the same. That is, the commands executed should be the same as before, with the same environment.

@milberg & @mjbludwig do you also use SLURM?

Looking at SLURM help tickets I see stuff like this. The SLURM FAQ also says something similar.
The user environment is re-populated from a copy of the environment taken when the job was submitted through sbatch, with the SLURM_* environment variables added in to it.
So somehow we corrupted the environment when we run srun.

@jeff.ohrstrom Yes, we are using Slurm. Besides adding sourcing the module environment setup .sh script in the cluster config, I later found that I needed to add it to the Job Composer templates as well.

OK, we clearly broke previous behavior.

We used to set SBATCH_EXPORT=NONE which makes it unclear to me how slurm used to find this function definition? We now just use the --export argument, but that’s only if there are other job_environment variables.

There’s a lot of talk in the tickets that generated this change, but it’s likely we’ll have to patch this as it looks like the previous behavior (however it happened) is expected and indeed a much better experience.

Glad I found this thread. We updated to 1.7.11 in production today and found that it broke all our jupyter apps. I had forgotten to test this in dev. It doesn’t know the ‘module’ command so nothing launches.

We will be fixing this in 1.7.13 so that the behavior is reverted. But the fixes in this PR should address the problem and be unaffected when 1.7.13 is released.

1 Like

We have an additional issue for our center in that users and groups create their own modules and source them in their .bashrc files. This work around provided doesn’t help for this issue. Any idea when you’ll be releasing version 1.7.13?


We have the patch in and we’re building now, so tomorrow we should be able to verify everything is working as it should.

Then we’ll be able to promote it to stable, so maybe tomorrow 5-28 and maybe Friday 5-29 depending (and it’s 1.7.14 now to also get a Safari/noVNC patch).

1 Like

Excellent! I can test this in our development setup too if that would help.

1.7.14 is currently built in the latest repo

You can try this out on your development host by running:

yum install
yum clean all
yum update ondemand

You can undo this change by running

yum remove ondemand-release-web-latest
yum install
yum clean all
yum downgrade ondemand

Thanks! This worked well for us in dev so we put it in production this afternoon. Appreciate the fast response on fixing this!

This has been promoted to stable, so you don’t need to pull it off our latest repo anymore, you can get it from the regular 1.7 repo.

Sites that have implemented this fix should not have issues updating directly. There should be no issue sourcing a file a second time (if it gets sourced at all, with the if block there).

Hi Jeff,

does this update also include the Linux Host Adapter fixes that you did for us?

Also, would you mind checking Linux Host Adapter feedback and responding to the questions I have there?


It does include the fixes for the linux host adapter. I have seen the feedback (and thank you for it!) and will comment on it now.