|
From: Sternberg, M. G. <ste...@an...> - 2023-04-23 17:08:43
|
Danny, To diagnose where PATH takes an unexpected turn on a test execution node, temporarily add to /etc/profile or a subordinate file: test -n "$PBS_JOBID" && set -x Results will land in stderr of a test job that you have PBS run there. Don't forget to undo the above. The "#PBS -V" directive is a rather blunt instrument to carry over env. vars from the submission node to the job execution node (and the first one only at that). The env. may contain state variables from the submission node that are irrelevant or misleading on the execution node. Preferable would be loading modules per the system and user's shell dotfiles, or if needed to vary by job then by "module load …" commands in the job script itself, preceding the main application command. With best regards, -- Michael Sternberg, Ph.D. Principal Scientific Computing Administrator Center for Nanoscale Materials Argonne National Laboratory > On Apr 23, 2023, at 01:13, Danny Sternkopf <Dan...@em...> wrote: > Hi Xavier, > in our case we have (workload manager) feature to export/transport all environment variables from the submit to the execution host (PBS # -V). It works except for PATH which gets overwritten by something very minimal. We don’t know why (yet), but this is not our topic here. Also it’s a very dangerous feature with high potential of messing up things completely. > > For module it means LOADEDMODULES u. _LMFILES_ as well as all other environment variables besides PATH are still intact. The system profile mechanism gets started (after that) and is trying to load the default modules (which doesn’t work for 4.x anymore): > … > >> Le ven. 21 avr. 2023 à 20:15, Danny Sternkopf <Dan...@em...> a écrit : >> >> … >> Basically what we want is to ‘semi-recover’ from a situation where only PATH is messed up (without going into details). >> >> So we just load the system default modules again to have at least a good enough environment. |
