On 10/15/2012 04:57 AM, Dave Love wrote:
Orion Poplawski <[email protected]> writes:
Well, looks like shell_start_mode is deprecated and doesn't do a whole
lot now.
It certainly does something, and is widely used. I should probably
remove the deprecation comment as I don't envisage removing the feature.
Ah, I see. So, my dmtcp_starter doesn't handle this then.
else
exec $SGE_STARTER_SHELL_PATH "$@"
fi
Somewhat funny - it looks like it tries to start the starter_method as
a "login shell", i.e. with a leading "-":
/var/spool/gridengine/castor/active_jobs/27713.1/trace:
10/10/2012 15:43:55 [1744:19855]:
execvp(/usr/share/gridengine/util/dmtcp_starter, "-dmtcp_starter"
"/var/spool/gridengine/castor/job_scripts/27713" "./foo" "7200"
"out.qsub")
This doesn't cause any problems for me, though starter scripts that
examine $0 might get confused.
Isn't that what they'd normally see?
Yes, they probably should, but it might not be expected. As common
programming idiom is to check $0 and act differently depending on the value of
it. Other than shells though, not many expect the command to possibly
prefixed by a "-". I could imagine a common starter script that did different
thing depending on it's name.
There are other things to consider in the starter, such as "-shell n".
I should have noted in the previous message that you probably don't want
to run a checkpoint method on slaves. When I suggested doing this as a
starter method, it would only have been for single-node jobs where files
in /tmp weren't an issue.
Noted, thanks.
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder Office FAX: 303-415-9702
3380 Mitchell Lane [email protected]
Boulder, CO 80301 http://www.nwra.com
_______________________________________________
users mailing list
[email protected]
https://gridengine.org/mailman/listinfo/users
