Hi
It certainly is the case that TMPDIR seems to be very difficult for
site admins to understand. I think it must be due to the poor choice
of name, TMPDIR seems to suggest to people that /tmp is the right
place. This is not necessarily a BAD place, as long as some thought
goes into things like the size of the disk partition on which /tmp
resides. Here for example on a dual-core node we have /tmp in its own
56 GB partition.
On the other hand, environment variables having "EDG" or "GLITE"
seem even worse. However one could always do something like
a) setup TMPDIR correctly
b) point the EU_PROJECT_ENV_VAR_OF_THE_DAY to this correctly-
configured TMPDIR
J "push the stick and dive" T
On Dec 16, 2008, at 20:10 , Maarten Litmaath wrote:
> Hi Stephen,
>
>>> Arguably the lcgpbs and pbs job managers ought to support the notion
>>> of running the job in a $TMPDIR subdirectory whenever possible.
>>> You could open a bug about that, but the gLite customization trick
>>> may well prove sufficient.
>> I think there are already about half a dozen bugs and tickets about
>> it!
>
> Indeed, for example:
>
> https://savannah.cern.ch/bugs/index.php?19138
>
> It refers e.g. to this bug:
>
> https://savannah.cern.ch/bugs/?3905
>
> Its discussion contains an argument by David Smith that $TMPDIR
> actually could be a rather _dangerous_ choice for jobs to use.
>
> The notion of a specific scratch area for jobs remains valid, though.
>
> The CREAM and WMS job wrappers could check for a new GLITE_WL_SCRATCH
> variable, but the GLITE_LOCAL_CUSTOMIZATION_DIR already gives the
> admin a generic hook for such functionality, as explained here:
>
> https://savannah.cern.ch/bugs/?18325
>
> The lcg-CE ought to have such functionality for jobs not submitted
> via the WMS, but apparently this has not been a big problem...
|