Löhnhardt, Benjamin wrote:
> Hi Martin,
>
> thanks for your prompt response! I suppose, that you are right with your
> guess. Maybe the SEG does not work correctly...
>
> In the meanwhile I have tested the following:
> After submitting a job via globus-ws, the job will be executed by lsf.
> Afterwards there is an entry in the logfile of lsf
> (/opt/hptc/lsf/top/work/hptclsf/logdir/lsb.acct). This entry seems to be
> equal (or similar) to the "old" lsf logfile. Mainly the version number of lsf
> is different.
>
> In /opt/globus/gt4/etc/globus-lsf.conf the right location of the lsf logfile
> is given: "log_path=/opt/hptc/lsf/top/work/hptclsf/logdir".
Good point. If the log_path pointed to a wrong location, that would have been
a good explanation...
>
> How can I run the SEG manually? I have tried
> "/opt/globus/gt4/libexec/globus-scheduler-event-generator -s LSF", but
> without success and with an error message: globus_scheduler_event_generator:
> Unable to dlopen module "/opt/globus/gt4/lib/libglobus_seg_LSF_gcc64dbg.la":
> file not found
2 things you can check:
1. Make sure /opt/globus/gt4/lib is set in your library search path environment
variable (The name of this variable depends on the system, but in most cases
it's $LD_LIBRARY_PATH)
2. I think you need to type LSF lower-case. Try
/opt/globus/gt4/libexec/globus-scheduler-event-generator -s lsf
(The library is very probably named libglobus_seg_lsf_gcc64dbg.la and not
libglobus_seg_LSF_gcc64dbg.la)
You might see a lot of output when you start that command. Wait until the
output stops. Then submit a job to LSF via WS-GRAM.
You should then see something like
001;1280934384;d96c164e-9fd9-11df-a8d3-0013d4c3b957:26714;2;0
001;1280934384;d96c164e-9fd9-11df-a8d3-0013d4c3b957:26714;8;0
on the console when you submit a job to LSF vi WS-GRAM (provided the SEG works
properly).
If the SEG doesn't spit out anything and the job is done in LSF, then
something is wrong.
In that case, submit a job to the scheduler 'fork' and see if the fork SEG
works ok, just to make sure you did the right things with the LSF SEG.
(Start the fork seg by 'globus-scheduler-event-generator -s fork' and submit
a 'fork' job via WS-GRAM)
Martin
>
> Btw: We use Globus 4.0.8 (I did not mentioned it in the last post.
>
> Regards,
> Benjamin
>
>
>> -----Ursprüngliche Nachricht-----
>> Von: Martin Feller [mailto:[email protected]]
>> Gesendet: Freitag, 30. Juli 2010 14:50
>> An: Löhnhardt, Benjamin
>> Cc: [email protected]
>> Betreff: Re: [gt-user] globus-ws with lsf does not work
>>
>> Hi,
>>
>> Just an educated guess:
>> I assume the problem is the scheduler event generator (SEG).
>> In Gram4, and I think also in Gram5, the SEG is responsible for
>> telling Gram about the status of the jobs in the job manager.
>> If the SEG doesn't tell Gram about job status, the job doesn't make
>> any progress from Gram's perspective.
>>
>> I think the SEG works on the log files of the job managers to get the
>> status information about the jobs.
>> If something changed in the logging format of the job manager, the SEG
>> may not be able to get the information anymore.
>> To confirm this I would probably run the SEG by hand and submit a
>> Gram job to old/new LSF and check if the SEG actually spits out
>> information on job status as it is processed in the job manager.
>>
>> Martin
>>
>> Löhnhardt, Benjamin wrote:
>>> Hello,
>>>
>>> we have a problem with globus and LSF as job manager. When we execute
>> a
>>> globus job via globus-ws on a client, on the server the job will be
>> handled
>>> by the lsf job manager "normally". The job even will be executed by
>> lsf
>>> itself, so that the test script was run on the server. However, the
>> client
>>> does not notice that the script was run successfully and waits. The
>> output on
>>> the client:
>>>
>>> -bash-3.1$ globusrun-ws -submit -s -F https://nimrod.med.uni-
>> goettingen.de
>>> -Ft LSF -c /tmp/test.sh
>>> Delegating user credentials...Done.
>>> Submitting job...Done.
>>> Job ID: uuid:c06227cc-9bc6-11df-80d4-00215af48192
>>> Termination time: 07/31/2010 10:39 GMT
>>>
>>> We have updated the lsf system on the server from 6.2 to 7.0. Has
>> anybody a
>>> hint why the client is waiting of a response by the server? How can
>> we fix
>>> this issue?
>>>
>>> Regards,
>>> Benjamin
>>>
>>>
>>>
>
