Print

---

Finally on this issue, after retracing my document-reading steps I 
thankfully realised that I wasn't going mad when I put the local submit 
script in /usr/bin, I read it here:

https://wiki.italiangrid.it/twiki/bin/view/CREAM/UserGuide#3_2_Forward_of_requirements_to_t

I've submitted a ticket asking for the documentation to be fixed.

Thanks again for the help,
Matt

On 09/17/2012 10:14 AM, Matt Doidge wrote:
> Thanks Rod and Chris.
>> I saw a similar thing for the sge_submit.sh script. I sent this to the
>> sge plugin supporters, and they fixed it - perhaps the lsf_submit.sh has
>> the same problem.
>>
>> "
>> local_submit_attributes_file=${GLITE_LOCATION:-/opt/glite}/bin/sge_local_submit_attributes.sh
>>
>>
>> to something like
>>
>> local_submit_attributes_file=${GLITE_LOCATION:-/usr}/libexec/sge_local_submit_attributes.sh
>>
>>
>> "
> Looking in the blah lsf_submit.sh scripts I do see the line:
> bls_local_submit_attributes_file=${blah_libexec_directory}/lsf_local_submit_attributes.sh
>
>
> which suggests that the /usr/libexec is the right place for my trusty
> local_submit script. I had a go at putting it in there and lo! Things
> seem to be working again. Thanks again guys!
>
> However looking in /usr/libexec/blah_load_config.sh
> I see there's the possibility of confusion if GLITE_LOCATION is still set:
>
> if [ "x$BLAHPD_LOCATION" != "x" -a -d "${BLAHPD_LOCATION}/libexec" ]; then
> blah_libexec_directory="${BLAHPD_LOCATION}/libexec"
> elif [ -d "${GLITE_LOCATION:-/opt/glite}/libexec" ]; then
> blah_libexec_directory="${GLITE_LOCATION:-/opt/glite}/libexec"
> else
> blah_libexec_directory="/usr/libexec"
> fi
>
> This could generate some oddness like Rob points out. Are references to
> GLITE_LOCATION defunct now?
>
>
>>
>> Cheers,
>> Rod.
>>
>>
>>
>>
>>
>> On 16 September 2012 17:00, Christopher J. Walker <[log in to unmask]
>> <mailto:[log in to unmask]>> wrote:
>>
>> On 16/09/12 14:54, Matt Doidge wrote:
>>
>> Hello,
>>
>> I've recently reinstalled our glite CREAM CE at Lancaster to an
>> EMI2 one
>> (on SL5). This submits to a shared LSF cluster. The trouble is
>> that this
>> cluster has a very harsh default job memory allocation. This
>> wasn't a
>> problem before, where we simply added a higher memory requirement to
>> lsf_local_job_attributes.sh.
>>
>> However with our new EMI2 install this script doesn't appear to
>> be being
>> called, thus causing jobs to hit the default memory limit and be
>> killed.
>> I'm not sure that I've put it in the right place, or maybe in
>> EMI there
>> needs to be some flag to tell blah to call this script? I
>> haven't set
>> anything implicitly, nor did I tell yaim to do anything funky. I did
>> have to manually change lsf_binpath on blah.config to the
>> obscure path
>> /opt/lsf/7.0/linux2.6-glibc2.__3-x86_64/bin that we use, rather
>> then the
>> default /usr/bin that it was set to. Not sure if that's relevant
>> though.
>>
>> I put the submit attributes in /usr/bin, which I believe is the
>> right
>> place, but it wouldn't be the first time I was wrong:
>>
>>
>> Our submit script (for SGE) is:
>>
>> [root@ce05 ~]# ll /usr/libexec/sge_local_submit___attributes.sh
>> -rwxr-xr-x 1 root root 5384 Jul 12 04:53
>> /usr/libexec/sge_local_submit___attributes.sh
>>
>>
>>
>> ll /usr/bin/lsf_local_submit___attributes.sh
>> -rwxr-xr-x 1 root root 343 Sep 13 14:07
>> /usr/bin/lsf_local_submit___attributes.sh
>>
>> The script itself hasn't changed from the glite version, it's
>> simply a
>> series of echoed job attributes.
>>
>> Our cream version is:
>> emi-cream-ce-1.1.0-4.sl5
>> and our blah version is:
>> glite-ce-blahp-1.18.1-2.sl5
>> We're running LSF 7.0, update 6.
>>
>> Thank you in advance for any help or advice,
>>
>> Matt
>>
>>
>>
>>
>> --
>> Tel. +49 89 289 14152