1. 23 Jan, 2012 4 commits
    • Morris Jette's avatar
      Merge branch 'slurm-2.3' · e0477c17
      Morris Jette authored
      e0477c17
    • Morris Jette's avatar
      e5ac37f1
    • jette's avatar
      Merge branch 'slurm-2.3' · 21fc4bfc
      jette authored
      21fc4bfc
    • Philip D. Eckert's avatar
      here it is · d254296c
      Philip D. Eckert authored
      Moe,
      
      Here it is, I have added a subroutine to env.c to
      unset the user's environment and then called it
      from sbatch in main. I also removed the comment
      from the sbatch man page indicating that it
      wasn't working the same for a regular user as
      it did for Moab. It should now be functionally
      the same.
      
      I think there is still a difference between how
      sbatch functions with an environment in a file
      than it does from when Moab excve'd the environment.
      However, I'm not sure what it would be at this
      point.
      
      Again,  for so many iterations....
      
      Phil
      d254296c
  2. 22 Jan, 2012 3 commits
    • jette's avatar
      Merge branch 'slurm-2.3' · 55785858
      jette authored
      55785858
    • Philip D. Eckert's avatar
      last one · 16e6fcd6
      Philip D. Eckert authored
      Moe,
      
      After doing more extensive testing, I came to realize
      that we had made a bad basic assumption. We believed
      that the user's environment should only be what was
      sent in the file via the --export-file option.
      
      However, that broke the previous behavior, especially
      in regard to Moab jobs. It also caused the SLURM
      defined environment variables to be lost as well.
      
      This patch will enable the correct behavior for Moab
      on top of SLURM whne using the --export-file option,
      but the behavior is less that pefect for using it
      stand alone with sbatch. When using the option with
      sbatch as a user, the file environment is read in,
      and then when the env_array_merge is made, some
      variables may get overwritten. This is good for
      the SLURM and MPI vairables, but not so good for
      others., The problem is trying to reconcile two
      sources of environment is very problematic.
      
      I also added a caveat in the man page.
      
      I made changes in my branch of SchedMD SLURM
      for 2.3, here is the patch.
      
      Phil
      16e6fcd6
    • jette's avatar
      Fix for job_cnt_comp underflow errors · 3c839428
      jette authored
      Fix race condition that could generate job_cnt_comp underflow errors on
      front-end architectures (Cray or IBM BlueGene systems).
      3c839428
  3. 21 Jan, 2012 2 commits
  4. 20 Jan, 2012 7 commits
  5. 19 Jan, 2012 9 commits
  6. 18 Jan, 2012 7 commits
  7. 17 Jan, 2012 8 commits