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 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 > > >
