1. 23 Jan, 2012 2 commits
    • Morris Jette's avatar
      e5ac37f1
    • 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 1 commit
    • 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
  3. 20 Jan, 2012 2 commits
  4. 19 Jan, 2012 5 commits
  5. 18 Jan, 2012 4 commits
  6. 17 Jan, 2012 2 commits
  7. 13 Jan, 2012 6 commits
  8. 11 Jan, 2012 1 commit
  9. 09 Jan, 2012 3 commits
  10. 28 Dec, 2011 1 commit
  11. 21 Dec, 2011 3 commits
  12. 20 Dec, 2011 1 commit
  13. 19 Dec, 2011 1 commit
  14. 17 Dec, 2011 3 commits
    • Morris Jette's avatar
      Note recent code changes · f455c48a
      Morris Jette authored
      f455c48a
    • Mark A. Grondona's avatar
      env import: clean up bracket count code · 9e0c20c6
      Mark A. Grondona authored
      When importing an exported shell function, the bracket count
      code didn't handle negative return value from _bracket_cnt(),
      so a shell function (or a shell variable starting with '(')
      would loop until the end of the env output.
      
      Since the test for no open bracket wasn't handled anyway, remove
      this and clean up _bracket_cnt() code (which now returns negative
      if there are more closing than opening brackets).
      
      Also, remove the unneded local integer bracket_cnt from the while
      loops and only continue processing while the bracket tally is > 0.
      
      Note: There are still many unhandled corner cases in this code.
      9e0c20c6
    • Mark A. Grondona's avatar
      env: fix shell function import · 013ac790
      Mark A. Grondona authored
      src/common/env.c:env_array_user_default() tries to import a "default"
      user environment by parsing the output of something like
      
       su - <user> -c "/bin/env" ( or "slurmstepd getenv")
      
      (or an equivalent) when the job is run with --get-user-env. There is some
      code that tries to detect and import exported bash shell functions, which
      usually have the form
      
       func=() { ...
       }
      
      into the job environment. However, one of the many problems with the
      code is that the test for bounds overflow:
      
                    if ((strlen(value) + strlen(line)) >
                        (sizeof(value) - 1))
                           break;
      
      useis sizeof(value) and value is a char *. This means that all multiline
      shell functions are truncated, and the following error appears in
      users batch script output:
      
       /bin/sh: func: line 1: syntax error: unexpected end of file
       /bin/sh: error importing function definition for `func'
      
      This patch fixes the bounds test.
      
      Similar cut-and-paste code in _load_env_cache() was also fixed.
      
      However, it should be noted that there are many other potential cases
      where shell functions will not be properly imported by this code.
      (For example, quoted unbalanced brackets used in the function)
      Someday this should be fixed.
      013ac790
  15. 15 Dec, 2011 1 commit
  16. 14 Dec, 2011 4 commits