On Thu, 26 Jun 2008, Charles Bacon wrote:
On Jun 26, 2008, at 12:45 PM, Steven Timm wrote:
1) using the globusrun-ws -submit -batch and globusrun-ws -monitor
combination both with the -subject option, it completes without errors.
The same combination, but requiring streaming as well,
we get this error:
[...]
globusrun-ws: Job failed: Staging error for RSL element fileCleanUp.
----------------------------
Any idea what might be causing the above error? Note
that we *do* get the standard output back somehow despite the error.
This sounds like Florian Lengyel's problem. What IP shows up in
$GL/etc/globus_wsrf_gram/globus_gram_fs_map_config.xml ? That controls the
GridFTP server used for cleanup operations.
I think you mean $GL/etc/gram-service/globus_gram_fs_map_config.xml
since the directory above doesn't exist. Anyway, there the IP listed
is fnpcosg1.fnal.gov, port 2811, all three times.
--------------------------------------------------------
I note that there's the following error in container-real.log:
2008-06-26 12:28:26,294 ERROR impl.QueryAggregatorSource
[Timer-8,pollGetMultiple:149] Exception Getting Multiple Resource
Properties from
https://131.225.166.2:9443/wsrf/services/ReliableFileTransferFactoryService:
java.rmi.RemoteException: Failed to serialize resource property
[EMAIL PROTECTED];
nested exception is:
org.apache.commons.dbcp.DbcpException: java.sql.SQLException: null,
message from server: "Host 'fnpcosg1.fnal.gov' is not allowed to connect to
this MySQL server".
Is this rft-related?
Yes, that would be the database server setup in
$GL/etc/globus_wsrf_rft/jndi-config.xml
jdbc:mysql://fnpcosg1:49151/rft_database?useServerPrepStmts=false
It appears that the problem here is that the VDT setup of
the RFT mysql database didn't allow rights for fnpcosg1.fnal.gov,
either rft or root, to access the mysql database. That
can be modified, if necessary.
2) Above you say that the globusrun-ws client will be modified in
globus 4.2 to expect the hostname to which it sent the
query originally... is this part of a bigger change in 4.2 about
the way that globus deals with hostnames? Is there any chance
it can be back-ported into the 4.0.x branch--or anything that
would break if it happened?
Don't know, this was the first I learned about it when I was talking to a
GRAM developer about your problem.
Is there any way that globus could move to a model similar
to that which Condor already uses, namely to allow a server to bind
to a particular IP only and use that IP for all communication
inbound and outbound? Since it's likely that the 4.0.x set of
clients will be with us for a while, it would be good to come
up with a solution that's more generic than requiring a client update.
Right. Don't know.
3) you agreed with me that moving my service ip to an alternate
network interface such as eth2 might help, but even so, it would
only help if that interface were the default route to the rest
of the world, wouldn't it?
[...]
If so, then it implies that for the moment, the globus container
must for consistency be run with a GLOBUS_HOSTNAME that matches the
default IP by which you talk to the rest of the world. Is this
correct?
Also don't know, it's been a while since I've done any real network work.
Your argument sounds reasonable, but if it were me, I'd just go
experimentally verify one way or the other.
Charles
--
------------------------------------------------------------------
Steven C. Timm, Ph.D (630) 840-8525
[EMAIL PROTECTED] http://home.fnal.gov/~timm/
Fermilab Computing Division, Scientific Computing Facilities,
Grid Facilities Department, FermiGrid Services Group, Assistant Group Leader.
