Martin Feller wrote: > Löhnhardt, Benjamin wrote: >>> 1. Make sure /opt/globus/gt4/lib is set in your library search path >>> environment >> /opt/globus/gt4/lib is set in $LD_LIBRARY_PATH. >> >>> 2. I think you need to type LSF lower-case. Try >> Lower case works :-) >> >> After submitting a job the output is: >> 001;1280936535;25852;1;0 >> 001;1280936538;25852;2;0 >> 001;1280936570;25852;8;0 >> > > Ok, this looks good. > >> Have you got any ideas why the messages does not reach the client? Can >> network configuration problems (firewall) cause it. Do you know which port(s) >> are used for the event to the client? >> > > Ah, why to the easy route if there is a complicated one... > Somehow I was focused on your statement "... new LSF ..." and thought it used > to work with old LSF or Fork. So maybe this: > > If your client is behind a firewall, then it's a pretty common thing that > notification messages are blocked. globusrun-ws, under the hood, starts a > notification > listener, which WS-GRAM uses to send the notification messages to. > If messages to the port of that listener are blocked for some reason, > globusrun-ws doesn't get any job status information from the server. > > To verify that: submit a job in batch/non-interactive mode and store the EPR > of the job. Then poll for status. Like > > globusrun-ws -submit -b -o job.epr ... > globusrun-ws -status -f job.epr
"globusrun-ws -status -j job.epr" is correct (-j, not -f) > > If you are able to get the job status this way, then the notification messages > keep stuck somewhere between the server and the client. > > Martin > >> Regards, >> Benjamin >> >> -- >> >> Benjamin Löhnhardt >> >> UNIVERSITÄTSMEDIZIN GÖTTINGEN >> GEORG-AUGUST-UNIVERSITÄT >> Abteilung Medizinische Informatik >> Robert-Koch-Straße 40 >> 37075 Göttingen >> Briefpost 37099 Göttingen >> Telefon +49-551 / 39-22842 >> [email protected] >> www.mi.med.uni-goettingen.de >> >> >> >
