Closed marksantcroos closed 8 years ago
putting CUs into their own process session might not strictly be necessary -- the agent exists for the lifetime of the units, so we should not be concerned about that failure mode (new session prevents the child from dying with the parent, and also prevents zombies in that context). Shall we try without on Joule? Would you mind giving it a try with set -m
removed in this line: https://github.com/radical-cybertools/radical.pilot/blob/devel/src/radical/pilot/agent/radical-pilot-spawner.sh#L405
Would you mind giving it a try with set -m removed
Doesn't seem to make a difference.
Hmm, strange... You can switch to popen meanwhile, per #475, but let me ponder over this one. In what context does the error come up? Could you have a look into the unit's subdir in the spawner tmp tree?
You can switch to popen meanwhile, per #475,
Done, thanks.
In what context does the error come up? Could you have a look into the unit's subdir in the spawner tmp tree?
-ECANNOTPARSE.
In what context does the error come up? Could you have a look into the unit's subdir in the spawner tmp tree?
-ECANNOTPARSE.
I mean the error Jobs not submitted by LoadLeveler cannot run because BG_ALLOW_LL_JOBS_ONLY is TRUE
: in what log did that show up, and what are the lines before it? Thanks!
I mean the error Jobs not submitted by LoadLeveler cannot run because BG_ALLOW_LL_JOBS_ONLY is TRUE: in what log did that show up,
This is the output of runjob, and therefore ends up in CU stdout.
and what are the lines before it?
None. Should there be any?
Since popen works and is the default anyway, I'll close this one.
With the new shell spawner CUs fail on Joule with:
This is likely because the shell spawner ends up with a fresh session/group or so.
According to the IBM documentation the admins on Joule changed the default. Would be good to find out why.
As a fall back we still have the popen spawner that works.