It seems that it is due to a bug at globus-scheduler-provider-lsf
adding the following lines to globus-scheduler-provider-lsf
echo scheduler xmlns=\http://mds.globus.org/batchproviders/2004/09\
http://mds.globus.org/batchproviders/2004/09%5C;
echo
Sorry for the lateness of this reply, but I'm not a GridFTP expert so
I was hoping someone who knows more than me would respond. That said,
I wouldn't expect this to work since AFAIK GridFTP does not support
access control based on X.509 extensions such as VOMS attribute
certificates or SAML
GridFTP should obey the GSI callout. If you have a gsi-authz.conf
file in your /etc/grid-security area, it should control the mapping
library used.
Looking at your connection log, it looks to be the case that you are
trying to connect on an internal network to the system that is
can you send the gridftp server logs as well?
Adam Bazinet wrote:
Hi,
I'm getting a strange error with every job I submit to Condor through my GT
4.2.0 installation. Job submits and runs fine, but fails during the
fileCleanUp stage. Here's one look at the error:
[EMAIL
Hmm,
Well I just turned on logging to /var/log/gridftp.log and guess what, it
works now, I'm not getting the error I was before! I doubt turning on
logging had anything to do with it though; perhaps it was just a mysterious
transient problem, because it has been a few hours since I last tried.
the error looks like a connection to the server fails when trying to obtain a session for the
delete. The server either never gets started or times out. can you send the configuration for the
the gridftp servers in question?
Adam Bazinet wrote:
Hmm,
Well I just turned on logging to
Sure, here it is:
service gsiftp
{
instances = 100
socket_type = stream
wait= no
user= root
env += GLOBUS_LOCATION=/export/work/globus-4.2.0
env +=
My thought right now is that you had more than 100 connections to the gridftp
server:
service gsiftp
{
instances = 100
when RFT tried to form the connection for the delete. The cache of connections for delete
operations and the cache of connections for the transfer handles
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello all, I'm trying to get gridftp working using the UDT protocol, as
it seems to be one of the only implementations of UDT in the world.
I've followed the instructions in URL1 (below), and it's not working.
When I run
Hii
I am trying to build GT4.0.7 toolkit on FC9 from source but I am getting
below error while building:
/usr/lib/ccache/gcc -DPACKAGE_NAME=\\ -DPACKAGE_TARNAME=\\
-DPACKAGE_VERSION=\\ -DPACKAGE_STRING=\\ -DPACKAGE_BUGREPORT=\\
-DPACKAGE=\globus_rls_client\ -DVERSION=\4.2\ -I.
Did you follow section 5.1.2 of the link that you point to at URL1. The
short answer is you need to use
$GLOBUS_LOCATION/bin/*pthr/shared/globus-url-copy for 2-party
(file-server or server-file) udt transfers to work.
Mike
Geoff Lovett wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
11 matches
Mail list logo
