xrootd / xrootd Goto Github PK

The XRootD central repository https://my.cdash.org/index.php?project=XRootD

License: Other

CMake 1.18% Makefile 0.04% CSS 0.10% HTML 0.01% Python 0.79% C++ 96.86% Shell 0.64% Perl 0.29% C 0.10%

xrootd's Introduction

XRootD: eXtended ROOT Daemon

The XRootD project provides a high-performance, fault-tolerant, and secure solution for handling massive amounts of data distributed across multiple storage resources, such as disk servers, tape libraries, and remote sites. It enables efficient data access and movement in a transparent and uniform manner, regardless of the underlying storage technology or location. It was initially developed by the High Energy Physics (HEP) community to meet the data storage and access requirements of the BaBar experiment at SLAC and later extended to meet the needs of experiments at the Large Hadron Collider (LHC) at CERN. XRootD is the core technology powering the EOS distributed filesystem, which is the storage solution used by LHC experiments and the storage backend for CERNBox. XRootD is also used as the core technology for global CDN deployments across multiple science domains.

XRootD is based on a scalable architecture that supports multi-protocol communications. XRootD provides a set of plugins and tools that allows the user to configure it freely to deploy data access clusters of any size, and which can include sophisticated features such as erasure coded files, various methods of authentication and authorization, as well as integration with other storage systems like ceph.

Documentation

General documentation such as configuration reference guides, and user manuals can be found on the XRootD website at http://xrootd.org/docs.html.

Supported Operating Systems

XRootD is officially supported on the following platforms:

RedHat Enterprise Linux 7 or later and their derivatives
Debian 11 and Ubuntu 22.04 or later
macOS 11 (Big Sur) or later

Support for other operating systems is provided on a best-effort basis and by contributions from the community.

Installation Instructions

XRootD is available via official channels in most operating systems. Installation via your system's package manager should be preferred.

In RPM-based distributions, like CentOS, Alma, Rocky, Fedora, etc, one can search and install XRootD packages with

$ sudo yum install xrootd

$ sudo dnf install xrootd

In RHEL-based distributions, it will be necessary to first install the EPEL release repository with yum install epel-release or dnf install epel-release.

If you would like to use our official repository for XRootD RPMs, you can enable it on RHEL-based distributions with

$ sudo curl -L https://cern.ch/xrootd/xrootd.repo -o /etc/yum.repos.d/xrootd.repo

and on Fedora with

$ sudo curl -L https://cern.ch/xrootd/xrootd-fedora.repo -o /etc/yum.repos.d/xrootd.repo

On Debian 11 or later, and Ubuntu 22.04 or later, XRootD can be installed via apt

$ sudo apt install xrootd-client xrootd-server python3-xrootd

On macOS, XRootD is available via Homebrew

$ brew install xrootd

XRootD can also be installed with conda, as it is also available in conda-forge:

$ conda config --add channels conda-forge
$ conda config --set channel_priority strict
$ conda install xrootd

Finally, it is possible to install the XRootD python bindings from PyPI using pip:

$ pip install xrootd

For detailed instructions on how to build and install XRootD from source code, please see docs/INSTALL.md in the main repository on GitHub.

User Support and Bug Reports

Bugs should be reported using GitHub issues. You can open a new ticket by clicking here.

For general questions about XRootD, please send a message to our user mailing list at [email protected] or open a new discussion on GitHub. Please check XRootD's contact page at http://xrootd.org/contact.html for further information.

Contributing

User contributions can be submitted via pull request on GitHub. We recommend that you create your own fork of XRootD on GitHub and use it to submit your patches. For more detailed instructions on how to contribute, please refer to the file docs/CONTRIBUTING.md.

xrootd's People

Stargazers

Watchers

Forkers

esindril jlsalmon bbockelm alja apeters1971 wangd osschar cgd8d mgmarino gganis artemharutyunyan kiryanov cms-externals ellert sponce ffurano fjammes bumfany otron lsst geonmo gbitzes khurtado jthiltges bmcann davidlt jpivarski glpatcern alexpearce fizmat chrisburr tkollegger simonmichal ktlim alisw graffaele rafalsikora jknedlik yolanda93 dmacks mpatrascoiu greenc-fnal kgizdov amadio jmakai jmuf kjamrog mlassnig yurivict cjones051073 benkrikler rd-alex-alex2006hw perilousapricot nsmith- edquist matyasselmeci sh1r4s3 apurbad paulmillar adriansev efajardo brianhlin atlantic777 cloud-pg mhaun0910 krasznaa costing cholmcc vokac chaen djw8605 sjha2048 basavyr oshadura akanksha-ahuja bkryza olifre stfc xxxrainzyian faluchet holajiawei dciangot rjones30 smithdh snafus externalrepositories thephisch nikoladze 4quarks awki226 ccaffy kreczko btovar nutufts zensanp vepadulano biozit juztas mannreis aashayarora

xrootd's Issues

xrootdfs crash

Hi,

We are seeing this error in the system logs

May 1 14:54:48 atl008 kernel: xrootdfs[3249] trap divide error rip:336920819a rsp:2af4fdc67710 error:0

for a static mount xrootdfs mount point -
xrootdfs /atlfs03/atlas fuse rdr=root://atlfs03.phy.duke.edu:1094//atlas,uid=54657 0 0

[root@atl008 ~]# yum list installed xrootd-fuse
Loaded plugins: downloadonly, kernel-module
Excluding Packages from Extra Packages for Enterprise Linux 5 - x86_64
Finished
Excluding Packages from VDT RPM repository - development versions for Redhat Enterprise Linux 5 and compatible
Finished
Installed Packages
xrootd-fuse.x86_64 1:3.3.1-1.slc5.xu installed

Here is the OS details -

[benjamin@atl008 ~]$ uname -a
Linux atl008.phy.duke.edu 2.6.18-348.4.1.el5 #1 SMP Tue Apr 16 15:42:58 EDT 2013 x86_64 x86_64 x86_64 GNU/Linux
[benjamin@atl008 ~]$ cat /etc/redhat-release
Scientific Linux release 5.9 (Boron)

Any ideas how I can get around this issue.

Thanks,

Doug

KRB5/GSI authentication in multithreaded applications

I have the following problem: the krb5 & gsi plugins use either an environment variable or if not set geteuid to define the token/proxy location for authentication.

In a multithreaded application it is not possible to have thread-private environment variables or effective uids thread-private, so I cannot use this mechanism unless I created a lock environment and set this variables for each individual XRootD call, which kills parallelism/performance.

The simplest way for me would be to pass the two relevant variables with each URL e.g.

"root://host//myfile?env:KRB5CCNAME=/tmp/krb5cc_QQWIUQIWUE1239873"

Incorrect logic in XrdSecsssID::genID(int)

XrdSecsssID::genID(int) constructs an XrdSecEntity object:

   myID.name = (Secure || XrdOucUtils:: UserName(geteuid(), pBuff, pgSz))
             ? (char *)"nobody"  : pBuff;
   myID.grps = (Secure || XrdOucUtils::GroupName(getegid(), gBuff, pgSz))
             ? (char *)"nogroup" : gBuff;

XrdOucUtils:: UserName returns 0 on success, however XrdOucUtils::GroupName returns the length of the group name. This means on group name of length 0 ( a 'failure') the un-initialized gBuff will be saved in myID.grps. To avoid changing the behavior of XrdOucutils::GroupName solution is:

   myID.name = (Secure || XrdOucUtils:: UserName(geteuid(), pBuff, pgSz))
             ? (char *)"nobody"  : pBuff;
   myID.grps = (Secure || XrdOucUtils::GroupName(getegid(), gBuff, pgSz) == 0)
             ? (char *)"nogroup" : gBuff;

kXR_locate error messages on exported paths

I get the following errors printed when running xrootd proxy server:

[2013-11-21 09:30:23.396278 -0800][Error ][XRootD ] [131.225.204.174:1094] Handling error while processing kXR_locate (path: /store, flags: none): [ERROR] Error response.

The messages seem to be harmless, since proxy server servers files from the exported location.

The error can be reproduced on xrootd master branch.

Here are links to xrootd log, configuration, and backtrace:
https://gist.github.com/alja/7586145
https://gist.github.com/alja/7586180
https://gist.github.com/alja/7586133

Failure to restart after upgrade

We upgraded at our site to version 3.3.3 overnight and the daemon failed to restart after the upgrade. A manual restart fixed this.

[XrdCl] does not always try full list of offered authentication methods

If the XRootD server offers several authentication methods and the authentication fails during the handshake, the new XrdCl does not continue to try alternative authentication methods.

[2013-05-08 22:28:19 +0200][Debug  ][File              ] [0xdc41610@root://localhost//proc/user/?mgm.cmd=cd&mgm.path=/eos/dev/raiddp/&mgm.option=s&eos.ruid=0&eos.rgid=0] Sending an open command
[2013-05-08 22:28:19 +0200][Debug  ][PostMaster        ] [localhost:1094] Found 1 address(es): [::127.0.0.1]:1094
[2013-05-08 22:28:19 +0200][Debug  ][AsyncSock         ] [localhost:1094 #0.0] Attempting connection to [::127.0.0.1]:1094
[2013-05-08 22:28:19 +0200][Debug  ][Poller            ] Adding socket 0xcbbd330 to the poller
[2013-05-08 22:28:19 +0200][Debug  ][AsyncSock         ] [localhost:1094 #0.0] Async connection call returned
[2013-05-08 22:28:19 +0200][Debug  ][XRootDTransport   ] [localhost:1094 #0.0] Sending out the initial hand shake + kXR_protocol
[2013-05-08 22:28:19 +0200][Debug  ][XRootDTransport   ] [localhost:1094 #0.0] Got the server hand shake response (type: manager [], protocol version 297)
[2013-05-08 22:28:19 +0200][Debug  ][XRootDTransport   ] [localhost:1094 #0.0] kXR_protocol successful (type: manager [], protocol version 297)
[2013-05-08 22:28:19 +0200][Debug  ][XRootDTransport   ] [localhost:1094 #0.0] Sending out kXR_login request, username: root
[2013-05-08 22:28:19 +0200][Debug  ][XRootDTransport   ] [localhost:1094 #0.0] Logged in
[2013-05-08 22:28:19 +0200][Debug  ][XRootDTransport   ] [localhost:1094 #0.0] Authentication is required: &P=krb5,host/[email protected],fwd&P=gsi,v:10300,c:ssl,ca:1d879c6c.0&P=unix&P=sss,0.13:/etc/eos.keytab
[2013-05-08 22:28:19 +0200][Debug  ][XRootDTransport   ] [localhost:1094 #0.0] Sending authentication data
sec_Client: protocol request for host localhost token='&P=krb5,host/[email protected],fwd&P=gsi,v:10300,c:ssl,ca:1d879c6c.0&P=unix&P=sss,0.13:/etc/eos.keytab'
sec_PM: Using krb5 protocol, args='host/[email protected],fwd'
[2013-05-08 22:28:19 +0200][Debug  ][XRootDTransport   ] [localhost:1094 #0.0] Trying to authenticate using krb5
Seckrb5: getCredentials
Seckrb5: FILE:/tmp/krb5cc_0_MVRZoE
Seckrb5: init context
Seckrb5: cc cache default
Seckrb5: context lock
Seckrb5: context locked
Seckrb5: Returned 3093 bytes of creds; p=host/[email protected]
[2013-05-08 22:28:19 +0200][Debug  ][XRootDTransport   ] [localhost:1094 #0.0] Sending more authentication data for krb5
Seckrb5: getCredentials
Seckrb5: FILE:/tmp/krb5cc_0_MVRZoE
Seckrb5: init context
Seckrb5: cc cache default
Seckrb5: context lock
Seckrb5: context locked
Seckrb5: get_krbFwdCreds: err getting forwarded ticket;Key version is not available
[2013-05-08 22:28:19 +0200][Debug  ][XRootDTransport   ] [localhost:1094 #0.0] Auth protocol handler for krb5 refuses to give us more credentials Seckrb5: Unable to get forwarded credentials; Key version is not available (p=host/[email protected]).
[2013-05-08 22:28:19 +0200][Error  ][AsyncSock         ] [localhost:1094 #0.0] Socket error while handshaking: [FATAL] Auth failed
[2013-05-08 22:28:19 +0200][Debug  ][AsyncSock         ] [localhost:1094 #0.0] Closing the socket
[2013-05-08 22:28:19 +0200][Debug  ][Poller            ] <[::127.0.0.1]:48212><--><[::127.0.0.1]:1094> Removing socket from the poller
[2013-05-08 22:28:19 +0200][Error  ][PostMaster        ] [localhost:1094 #0] Unable to recover: [FATAL] Auth failed.
[2013-05-08 22:28:19 +0200][Error  ][XRootD            ] [localhost:1094] Impossible to send message . Trying to recover.
[2013-05-08 22:28:19 +0200][Error  ][XRootD            ] [localhost:1094] Handling error while processing : [FATAL] Auth failed.
[2013-05-08 22:28:19 +0200][Debug  ][File              ] [0xdc41610@root://localhost//proc/user/?mgm.cmd=cd&mgm.path=/eos/dev/raiddp/&mgm.option=s&eos.ruid=0&eos.rgid=0] Open has returned with status [FATAL] Auth failed
[2013-05-08 22:28:19 +0200][Debug  ][File              ] [0xdc41610@root://localhost//proc/user/?mgm.cmd=cd&mgm.path=/eos/dev/raiddp/&mgm.option=s&eos.ruid=0&eos.rgid=0] Error while opening at localhost:1094: [FATAL] Auth failed

xrdcopy ignores trailing / on non-existing directory destination, creates file instead

Assume an attempt to copy files into some directory, hence last argument to "xrdcopy" is supposed to be a directory, and user adds a trailing "/".

(if the directory exists, xrdcopy behaves as expected (even without "/") - ok)
if the directory does not exists, xrdcopy creates instead a file, and ignores the "/". Instead, should either create the missing directory, or at least give an error.

$ rpm -qf which xrdcopy
1:xrootd-client-3.3.3-1.el6.x86_64
~$ xrdcopy /etc/group root://eospps//eos/iven/dir/
[100%][==================================================] [1k/1k]
~$ xrdcopy /etc/group root://eospps//eos/iven/nodir/
[100%][==================================================] [1k/1k]
~$ xrd eospps ls /eos/iven
dr-x(019) 0 2013-10-03 07:47:28 /eos/iven/dir
-r--(016) 1098 2013-10-03 07:47:36 /eos/iven/nodir

Legacy options (-OD, -OS) broken in xrdcp (xroot v3.3.1-1)

Hi,

Usage of legacy options -OD or -OS are missing the inclusion of a "?" between the file name and the option itself, hence the files cannot be written:

[root@lxbst2320 ]# xrdcp /etc/group root://localhost//eos/pps/test/test.x -ODeos.space=default
xrdcp: Copy to localhost.localdomain failed on open!
xrdcp: Unable to accept path name - illegal characters - use only A-Z a-z 0-9 / SPACE .-_#:^ /eos/pps/test/test.xeos.space=default; Invalid or incomplete multibyte or wide character

While adding manually the magic "?" overcome the issue:

[root@lxbst2320 ~]# xrdcp /etc/group root://localhost//eos/pps/test/test.x -OD?eos.space=default
[xrootd] Total 0.00 MB |====================| 100.00 % [inf MB/s]

-OD and -OS options need to be fixed to include the magic charachter.

Thanks in advance.
Xavi.

xrdcopy permissions on files

This is not a bug but more of a question.
I see that the old xrdcp command used to set the permissions on the newly created files as: -rw- r-- r-- i.e 644 but the new xrdcopy seems to use by default rw- --- --- i.e. 600. I just had some of my old test failing because of this... since the stat information returned for such a file fails the IsReadable test.
Is this on purpose?

eg.
[esindril@pcitdss1401 ~]$ xrdcopy -f /etc/passwd root://localhost:1091//tmp/demo.dat
[100%][==================================================] [2k/2k]
[esindril@pcitdss1401 ~]$ ls -lrt /tmp/demo.dat
-rw-------. 1 xrootd xrootd 2199 Oct 9 16:49 /tmp/demo.dat

while with the old one:
[esindril@pcitdss1401 ~]$ xrdcp -f /etc/passwd root://localhost:1091//tmp/demo1.dat
[esindril@pcitdss1401 ~]$ ls -lrt /tmp/demo1.dat
-rw-r--r--. 1 xrootd xrootd 2199 Oct 9 16:49 /tmp/demo1.dat

"xrdcp -f" does not force overwrite with directory destinations

"-f" should allow to write over an existing file. This fails if the destination is a directory (which already contains that file), succeeds if the full path is given:

/tmp$ xrdcp -f file-1k.1 root://eospps//eos/geotest/wigner/1k/
xrdcp: Copy to lxbst2320.cern.ch failed on open!
xrdcp: Unable to create file /eos/geotest/wigner/1k; File exists
/tmp$ xrdcp -f file-1k.1 root://eospps//eos/geotest/wigner/1k/file-1k.1
[xrootd] Total 0.00 MB |====================| 100.00 % [inf MB/s]
/tmp$ rpm -qf which xrdcp
1:xrootd-client-3.3.3-1.slc6.x86_64

Suggest to also make the "directory destination" case work, i.e. overwrite the existing file.

cmsd state check

We need a way to test if cmsd is live/dead/responding properly. I don't know what is the best definition of "responding" properly.

int XrdSysCondVar::Wait(int sec) does not wait the requested period

The implementation of XrdSysCondVar::Wait(int sec) is 'wrong' since it will wait an arbitrary time between 0 and 1 seconds depending at which time during a unix timestamp period it is called.

The implementation should be:

int XrdSysCondVar::Wait(int sec)
{
 return WaitMS(sec*1000);
}

This also avoids most of the 1:1 duplicated code between Wait and WaitMS.

don't make stupid permission checks on certificates

Hi.

When using certiifcates with xrootd, it apparently checks to have exactly mode 644 / 400.
Please stop doing such crappy things... people don't want to make copies of hostcerts for each service they run, and whenever the certs need to be exchanged, go through all these locations.
It's common use within the grid to have /etc/grid-security/hostcert|key.pem and it should be possible to simply use them.

When you insist though on the above nodes, using ACLs to allow the xrootd user reading the key becomes impossible.

Cheers,
Chris.

Built-in poller occasionally not invoking callbacks on OSX

Hi,

When using the built-in poller on OSX, there is an occasional condition whereby a client thread (thread 1) which attempts to connect a socket asynchronously does not get called back. This locks up the client until the connect operation times out.

This doesn't happen with the libevent poller. The frequency of occurrence of the problem can be increased by adding time delays in the client code, so it's more than likely a timing issue (maybe the poller invoking the callback too early?).

Here are the stack traces:

Thread 6 (process 17596):
#0  0x00007fff8d9da112 in sem_wait ()
#1  0x00000001000736c1 in XrdSysSemaphore::Wait (this=0x100512950) at XrdSysPthread.hh:335
#2  0x00000001000da19f in XrdCl::SyncQueue<XrdCl::JobManager::JobHelper>::Get (this=0x100512a78) at XrdClSyncQueue.hh:66
#3  0x00000001000d9fa3 in XrdCl::JobManager::RunJobs (this=0x100512a60) at XrdClJobManager.cc:133
#4  0x00000001000d9cbd in RunRunnerThread (arg=0x100512a60) at XrdClJobManager.cc:33
#5  0x00007fff913497a2 in _pthread_start ()
#6  0x00007fff913361e1 in thread_start ()

Thread 5 (process 17596):
#0  0x00007fff8d9da112 in sem_wait ()
#1  0x00000001000736c1 in XrdSysSemaphore::Wait (this=0x100512950) at XrdSysPthread.hh:335
#2  0x00000001000da19f in XrdCl::SyncQueue<XrdCl::JobManager::JobHelper>::Get (this=0x100512a78) at XrdClSyncQueue.hh:66
#3  0x00000001000d9fa3 in XrdCl::JobManager::RunJobs (this=0x100512a60) at XrdClJobManager.cc:133
#4  0x00000001000d9cbd in RunRunnerThread (arg=0x100512a60) at XrdClJobManager.cc:33
#5  0x00007fff913497a2 in _pthread_start ()
#6  0x00007fff913361e1 in thread_start ()

Thread 4 (process 17596):
#0  0x00007fff8d9da112 in sem_wait ()
#1  0x00000001000736c1 in XrdSysSemaphore::Wait (this=0x100512950) at XrdSysPthread.hh:335
#2  0x00000001000da19f in XrdCl::SyncQueue<XrdCl::JobManager::JobHelper>::Get (this=0x100512a78) at XrdClSyncQueue.hh:66
#3  0x00000001000d9fa3 in XrdCl::JobManager::RunJobs (this=0x100512a60) at XrdClJobManager.cc:133
#4  0x00000001000d9cbd in RunRunnerThread (arg=0x100512a60) at XrdClJobManager.cc:33
#5  0x00007fff913497a2 in _pthread_start ()
#6  0x00007fff913361e1 in thread_start ()

Thread 3 (process 17596):
#0  0x00007fff8d9d9386 in __semwait_signal ()
#1  0x00007fff913d3800 in nanosleep ()
#2  0x00007fff913d368a in sleep ()
#3  0x000000010008c33f in XrdCl::TaskManager::RunTasks (this=0x100512980) at XrdClTaskManager.cc:238
#4  0x000000010008b49d in RunRunnerThread (arg=0x100512980) at XrdClTaskManager.cc:36
#5  0x00007fff913497a2 in _pthread_start ()
#6  0x00007fff913361e1 in thread_start ()

Thread 2 (process 17596):
#0  0x00007fff8d9d9f96 in poll ()
#1  0x00000001002e8be7 in XrdSys::IOEvents::PollPoll::Begin (this=0x100512d20, syncsem=0x7fff5fbfec98, retcode=@0x7fff5fbfec90, eTxt=0x7fff5fbfec88) at XrdSysIOEventsPollPoll.icc:191
#2  0x00000001002e6181 in XrdSys::IOEvents::BootStrap::Start (parg=0x7fff5fbfec80) at /Users/jussy/repos/xrootd/src/XrdSys/XrdSysIOEvents.cc:110
#3  0x00000001002e3f55 in XrdSysThread_Xeq (myargs=0x100512e60) at /Users/jussy/repos/xrootd/src/XrdSys/XrdSysPthread.cc:86
#4  0x00007fff913497a2 in _pthread_start ()
#5  0x00007fff913361e1 in thread_start ()

Thread 1 (process 17596):
#0  0x00007fff8d9da112 in sem_wait ()
#1  0x00000001000736c1 in XrdSysSemaphore::Wait (this=0x100511640) at XrdSysPthread.hh:335
#2  0x00000001000993f9 in XrdCl::SyncResponseHandler::WaitForResponse (this=0x7fff5fbff3c0) at XrdClMessageUtils.hh:85
#3  0x0000000100097eda in XrdCl::MessageUtils::WaitForResponse<XrdCl::StatInfo> (handler=0x7fff5fbff3c0, response=@0x7fff5fbff5d0) at XrdClMessageUtils.hh:135
#4  0x000000010009363b in XrdCl::FileSystem::Stat (this=0x100512530, path=@0x7fff5fbff600, response=@0x7fff5fbff5d0, timeout=0) at XrdClFileSystem.cc:709
#5  0x0000000100008344 in DoStat (fs=0x100512530, env=0x100512380, args=@0x7fff5fbff7e0) at XrdClFS.cc:740
#6  0x0000000100010ae7 in XrdCl::FSExecutor::Execute (this=0x1005124f0, commandline=@0x7fff5fbff930) at XrdClFSExecutor.cc:100
#7  0x000000010000ad0a in ExecuteCommand (ex=0x1005124f0, commandline=@0x7fff5fbff930) at XrdClFS.cc:1023
#8  0x000000010000b690 in ExecuteCommand (url=@0x7fff5fbff9c8, argc=2, argv=0x7fff5fbffad8) at XrdClFS.cc:1143
#9  0x000000010000ba0c in main (argc=4, argv=0x7fff5fbffac8) at XrdClFS.cc:1179

Cheers,
Justin

Built-in poller occasionally not invoking callbacks on OSX

Hi,

Here are the stack traces:

Thread 6 (process 17596):
#0  0x00007fff8d9da112 in sem_wait ()
#1  0x00000001000736c1 in XrdSysSemaphore::Wait (this=0x100512950) at XrdSysPthread.hh:335
#2  0x00000001000da19f in XrdCl::SyncQueue<XrdCl::JobManager::JobHelper>::Get (this=0x100512a78) at XrdClSyncQueue.hh:66
#3  0x00000001000d9fa3 in XrdCl::JobManager::RunJobs (this=0x100512a60) at XrdClJobManager.cc:133
#4  0x00000001000d9cbd in RunRunnerThread (arg=0x100512a60) at XrdClJobManager.cc:33
#5  0x00007fff913497a2 in _pthread_start ()
#6  0x00007fff913361e1 in thread_start ()

Thread 5 (process 17596):
#0  0x00007fff8d9da112 in sem_wait ()
#1  0x00000001000736c1 in XrdSysSemaphore::Wait (this=0x100512950) at XrdSysPthread.hh:335
#2  0x00000001000da19f in XrdCl::SyncQueue<XrdCl::JobManager::JobHelper>::Get (this=0x100512a78) at XrdClSyncQueue.hh:66
#3  0x00000001000d9fa3 in XrdCl::JobManager::RunJobs (this=0x100512a60) at XrdClJobManager.cc:133
#4  0x00000001000d9cbd in RunRunnerThread (arg=0x100512a60) at XrdClJobManager.cc:33
#5  0x00007fff913497a2 in _pthread_start ()
#6  0x00007fff913361e1 in thread_start ()

Thread 4 (process 17596):
#0  0x00007fff8d9da112 in sem_wait ()
#1  0x00000001000736c1 in XrdSysSemaphore::Wait (this=0x100512950) at XrdSysPthread.hh:335
#2  0x00000001000da19f in XrdCl::SyncQueue<XrdCl::JobManager::JobHelper>::Get (this=0x100512a78) at XrdClSyncQueue.hh:66
#3  0x00000001000d9fa3 in XrdCl::JobManager::RunJobs (this=0x100512a60) at XrdClJobManager.cc:133
#4  0x00000001000d9cbd in RunRunnerThread (arg=0x100512a60) at XrdClJobManager.cc:33
#5  0x00007fff913497a2 in _pthread_start ()
#6  0x00007fff913361e1 in thread_start ()

Thread 3 (process 17596):
#0  0x00007fff8d9d9386 in __semwait_signal ()
#1  0x00007fff913d3800 in nanosleep ()
#2  0x00007fff913d368a in sleep ()
#3  0x000000010008c33f in XrdCl::TaskManager::RunTasks (this=0x100512980) at XrdClTaskManager.cc:238
#4  0x000000010008b49d in RunRunnerThread (arg=0x100512980) at XrdClTaskManager.cc:36
#5  0x00007fff913497a2 in _pthread_start ()
#6  0x00007fff913361e1 in thread_start ()

Thread 2 (process 17596):
#0  0x00007fff8d9d9f96 in poll ()
#1  0x00000001002e8be7 in XrdSys::IOEvents::PollPoll::Begin (this=0x100512d20, syncsem=0x7fff5fbfec98, retcode=@0x7fff5fbfec90, eTxt=0x7fff5fbfec88) at XrdSysIOEventsPollPoll.icc:191
#2  0x00000001002e6181 in XrdSys::IOEvents::BootStrap::Start (parg=0x7fff5fbfec80) at /Users/jussy/repos/xrootd/src/XrdSys/XrdSysIOEvents.cc:110
#3  0x00000001002e3f55 in XrdSysThread_Xeq (myargs=0x100512e60) at /Users/jussy/repos/xrootd/src/XrdSys/XrdSysPthread.cc:86
#4  0x00007fff913497a2 in _pthread_start ()
#5  0x00007fff913361e1 in thread_start ()

Thread 1 (process 17596):
#0  0x00007fff8d9da112 in sem_wait ()
#1  0x00000001000736c1 in XrdSysSemaphore::Wait (this=0x100511640) at XrdSysPthread.hh:335
#2  0x00000001000993f9 in XrdCl::SyncResponseHandler::WaitForResponse (this=0x7fff5fbff3c0) at XrdClMessageUtils.hh:85
#3  0x0000000100097eda in XrdCl::MessageUtils::WaitForResponse<XrdCl::StatInfo> (handler=0x7fff5fbff3c0, response=@0x7fff5fbff5d0) at XrdClMessageUtils.hh:135
#4  0x000000010009363b in XrdCl::FileSystem::Stat (this=0x100512530, path=@0x7fff5fbff600, response=@0x7fff5fbff5d0, timeout=0) at XrdClFileSystem.cc:709
#5  0x0000000100008344 in DoStat (fs=0x100512530, env=0x100512380, args=@0x7fff5fbff7e0) at XrdClFS.cc:740
#6  0x0000000100010ae7 in XrdCl::FSExecutor::Execute (this=0x1005124f0, commandline=@0x7fff5fbff930) at XrdClFSExecutor.cc:100
#7  0x000000010000ad0a in ExecuteCommand (ex=0x1005124f0, commandline=@0x7fff5fbff930) at XrdClFS.cc:1023
#8  0x000000010000b690 in ExecuteCommand (url=@0x7fff5fbff9c8, argc=2, argv=0x7fff5fbffad8) at XrdClFS.cc:1143
#9  0x000000010000ba0c in main (argc=4, argv=0x7fff5fbffac8) at XrdClFS.cc:1179

Cheers,
Justin

[XrdCl] xrdfs does not properly handle empty directories

When doing an ls on an empty directory xrdfs returns an error:

ls /tmp/empty
[ERROR] Invalid response

This is because the server doesn't return anything but an OK response. The server never returns the "." and ".." directory entries. So, xrdfs should treat this as an empty directory response which is OK.

xrdcopy is CPU bound and limiting on 10Gbit networks

Doing some testing I have seen that the copy command is CPU bound and limits file downloads (serverside cached file 4Gb) to ~ 770 MB/s

The single stream performance is ~ 350 MB/s to reach 770 MB/s I need to use 15 parallel sockets and export XRD_CPPARALLELCHUNKS=10

It is mainly system time.

model name : Intel(R) Xeon(R) CPU L5520 @ 2.27GHz
stepping : 5
cpu MHz : 1600.000
cache size : 8192 KB

The poller implementation has marginal effect (<2%) on the performance.

I can saturate the 10GB network by running two copy commands.

PS: the default 'xrdcp' command has weird performance ranging from 40-500 MB/s with regular hick-ups ...

[XrdCl] Segmentation fault with eoscp

I am currently using:

XRootD:

    commit 41831847ceff40c1b358f55fa686490ab12c2df9
    Author: Lukasz Janyst <[email protected]>
    Date:   Fri Apr 26 20:20:09 2013 +0200

        [Release Notes] Update for 3.3.2

EOS:

    commit aca0a59e18ebf3f5ba5cd06330e91f392b8265a7
    Author: Andreas Peters <[email protected]>
    Date:   Mon May 27 16:09:38 2013 +0200

        RPM: move to build 7

While doing: eoscp -d -S 1 -D 1 root://pcitdss1400.cern.ch//eos/raiddp/test100.rain /tmp/output1.txt

Where in EOS:

EOS Console [root://localhost] |/eos/> attr ls raiddp
sys.forced.blockchecksum="crc32c"
sys.forced.blocksize="1M"
sys.forced.checksum="crc32c"
sys.forced.layout="raiddp"
sys.forced.nstripes="6"
EOS Console [root://localhost] |/eos/raiddp/> fileinfo test100.rain --fullpath
  File: '/eos/raiddp/test100.rain'  Size: 4711176
Modify: Mon May 27 11:22:07 2013 Timestamp: 1369646527.488479000
Change: Mon May 27 11:22:07 2013 Timestamp: 1369646527.115517384
  CUid: 0 CGid: 0  Fxid: 00035459 Fid: 218201    Pid: 9593
XStype: crc32c    XS: 0f aa 16 21
raiddp Stripes: 6 Blocksize: 1M *******
  #Rep: 6
<#> <fs-id> #................................................................................................................
            #                   host #   id #     schedgroup #           path #     boot # configstatus #      drain # active
            #................................................................................................................
  0       1      pcitdss1400.cern.ch      1          default /home/data/eos1/     booted             rw      nodrain   online /home/data/eos1/00000015/00035459
  1       4      pcitdss1400.cern.ch      4          default /home/data/eos4/     booted             rw      nodrain   online /home/data/eos4/00000015/00035459
  2       3      pcitdss1400.cern.ch      3          default /home/data/eos3/     booted            off      nodrain   online /home/data/eos3/00000015/00035459
  3       2      pcitdss1400.cern.ch      2          default /home/data/eos2/     booted             rw      nodrain   online /home/data/eos2/00000015/00035459
  4       6      pcitdss1400.cern.ch      6          default /home/data/eos6/     booted             rw      nodrain   online /home/data/eos6/00000015/00035459
  5       5      pcitdss1400.cern.ch      5          default /home/data/eos5/     booted             rw      nodrain   online /home/data/eos5/00000015/00035459
*******

You can see that one file system is disabled so the recovery process kicks in.
I get a segmentation fault at the end of the transfer when the whole file is copied over and has the correct checksum.
Using gdb I only get:

(gdb) thread apply all bt

Thread 1 (Thread 0x7ffff71fc780 (LWP 28250)):
#0  0x0000003ef7876205 in malloc_consolidate () from /lib64/libc.so.6
#1  0x0000003ef7878ba8 in _int_free () from /lib64/libc.so.6
#2  0x00007ffff7d8b92c in XrdCl::Channel::~Channel (this=0x665870, __in_chrg=<value optimized out>) at /home/esindril/Programs/xrootd_github/src/XrdCl/XrdClChannel.cc:244
#3  0x00007ffff7d89b41 in XrdCl::PostMaster::Finalize (this=0x65b580) at /home/esindril/Programs/xrootd_github/src/XrdCl/XrdClPostMaster.cc:101
#4  0x00007ffff7d7ee62 in XrdCl::DefaultEnv::Finalize () at /home/esindril/Programs/xrootd_github/src/XrdCl/XrdClDefaultEnv.cc:394
#5  0x0000003ef783613d in __cxa_finalize () from /lib64/libc.so.6
#6  0x00007ffff7d76586 in __do_global_dtors_aux () from /usr/local/lib64/libXrdCl.so.1
#7  0x0000000000000000 in ?? ()

XrdOucUtils::GroupName not properly checking return value of getgrgid_r

There are 2 issues:

The code is currently checking if "errno" is == ERANGE, but getgrgid_r is thread safe and returns the error code.
Even if getgrgid_r succeeds, the code needs to check the value of gEnt since it may be NULL.

From http://pubs.opengroup.org/onlinepubs/009695299/functions/getgrgid.html

int getgrgid_r(gid_t gid, struct group _grp, char *buffer,
size_t bufsize, struct group *_result);
...
The getgrgid_r() function shall update the group structure pointed to by grp and store a pointer to that structure at the location pointed to by result.... A NULL pointer shall be returned at the location pointed to by result on error or if the requested entry is not found.

Provide public methods to adjust log levels from C++ code

It turns out that CMSSW defines "likely" and "unlikely" symbols in its own source code - XrdClOptimizers.hh redefines these, resulting in an error.

Can you put them inside the XrdCl namespace?

xrdcp client writing TURL options in the filename

Issuing a copy command:

08:37:10:xavierc3@lxplus0013:~$ uname -a
Linux lxplus0013 2.6.32-358.6.1.el6.x86_64 #1 SMP Wed Apr 24 09:18:30 CEST 2013 x86_64 x86_64 x86_64 GNU/Linux

08:41:41:xavierc3@lxplus0013:~$ export STAGE_HOST=castorpublic

08:41:41:xavierc3@lxplus0013:~$ export STAGE_SVCCLASS=default

08:41:47:xavierc3@lxplus0013:~$ xrdcp root://$STAGE_HOST//castor/cern.ch/compass/data/2006/oracle_dst/W35/mDST/mDST-50936-2-7.root?svcClass=$STAGE_SVCCLASS /tmp/
[xrootd] Total 1434.37 MB |====================| 100.00 % [117.6 MB/s]

Ends up creating this file name:

08:42:09:xavierc3@lxplus0013:~$ ls -ltr /tmp/
[...]
-rw-r--r--. 1 xavierc3 c3 1504050038 May 17 08:42 mDST-50936-2-7.root?svcClass=default

While passing the options through -OS works fine:

08:50:50:xavierc3@lxplus0013:~$ xrdcp root://$STAGE_HOST//castor/cern.ch/compass/data/2006/oracle_dst/W35/mDST/mDST-50936-2-7.root -OSsvcClass=$STAGE_SVCCLASS /tmp/xavierc3/
[xrootd] Total 1434.37 MB |====================| 100.00 % [114.1 MB/s]

08:51:11:xavierc3@lxplus0013:~$ ls -ltr /tmp/xavierc3/
total 1468804
-rw-r--r--. 1 xavierc3 c3 1504050038 May 17 08:51 mDST-50936-2-7.root

I couldn't reproduce this in xrdcp v3.3.2, but probably you may want to commit the fix to v3.3.1.

XrdCl::FileSystem -- PrepareFlags has no "None" entry

It should be possible to set no flags for XrdCl::FileSystem::Prepare, no? Looking at the source code, I can't see how to do this without passing at least one flag.

Xrootd in proxy mode dies

I run an xrootd proxy server as part of our cluster's contribution to
the ATLAS Federated Xrootd setup. This afternoon the xrootd process
crashed. I have a core file and the xrootd log for today.

I noticed from the log that the last Xrootd call was in
/usr/lib64/libXrdSecgsiVOMS.so

and that the time might have been suspicious since this would be the
time that an hourly cron process updates certs and crls.

The core, log, and configuration file are available at:
http://www-hep.uta.edu/~mcguigan/xrootd_crash/

We are running
xrootd-server-3.3.1-1.slc6.xu.x86_64
xrootd-debuginfo-3.3.3-1.slc6.x86_64
xrootd-client-3.3.1-1.slc6.xu.x86_64
xrootd-server-atlas-n2n-plugin-1.0.1-1.el6.x86_64
xrootd-libs-3.3.1-1.slc6.xu.x86_64
vomsxrd-0.2.0-1.el6.x86_64

Third party copy API does not allow cancelling

This is needed by FTS3, since transfers may be canceled for various reasons, and they need to finish gracefully.

cope with slowly-non-resolving IPs

It seems that xrootd does a reverse DNS lookup rather early on a connection. In the case where the IP does not resolve AND takes a while about this (authoritative nameserver is down, several retries), this may lead to a denial-of-service. Perhaps there are ways to mitigate this (resolve via thread pool, do not resolve once threads are busy; do not resolve IPs for which a DNS request is outstanding etc)?

Actual case seen was EOSALICE being blocked by a handful of connections from the ALICE/CMS LCG Tier-2 in Kolkata (144.16.112.12) - logged connections per hour are ~100, i.e. roughly one per minute (other non-resolving IPs are logged at much higher rates). As a workaround, we have blocked that IP, this is not really a satisfactory situation for anybody involved.
We have not used the "nodnr" option, since the impact on other parts of the system (binding certain auth types to machines, or EOS-internal per-diskserver statekeeping are not understood). We are running a caching nameserver locally, but this does not help.

"xrdcopy" man page: document "--tpc first" vs "--tpc only"

the sub-options "first" or "only" are mandatory for the "--tpc" option, but are not mentioned in the "xrdcopy" manpage (neither in the option summary nor lower down in the "--tpc" explanation - please add.

A problem (deadlock) in krb5 on SLC6 under heavy load

We have a problem in the krb5 plugin happening in castor public instance being under heavy load. The problem is that most of the threads are stuck in:

Thread 4103 (Thread 0x7fd45ec2c700 (LWP 22554)):
#0  0x0000003cefe0e054 in __lll_lock_wait () from /lib64/libpthread.so.0
#1  0x0000003cefe09388 in _L_lock_854 () from /lib64/libpthread.so.0
#2  0x0000003cefe09257 in pthread_mutex_lock () from /lib64/libpthread.so.0
#3  0x00007fd45b0ef907 in Lock (this=0x7fd454018eb0, cred=0x7fd45ec2bd90, parms=0x7fd45ec2bdd8, error=0x7fd45ec2b550) at /usr/src/debug/xrootd/xrootd/src/XrdSys/XrdSysPthread.hh:149
#4  XrdSecProtocolkrb5::Authenticate (this=0x7fd454018eb0, cred=0x7fd45ec2bd90, parms=0x7fd45ec2bdd8, error=0x7fd45ec2b550) at /usr/src/debug/xrootd/xrootd/src/XrdSeckrb5/XrdSecProtocolkrb5.cc:468
#5  0x000000000041f9cb in XrdXrootdProtocol::do_Auth (this=0x7fd253168810) at /usr/src/debug/xrootd/xrootd/src/XrdXrootd/XrdXrootdXeq.cc:147
#6  0x0000003cf264ebf9 in XrdLink::DoIt (this=0x2136c78) at /usr/src/debug/xrootd/xrootd/src/Xrd/XrdLink.cc:442
#7  0x0000003cf2652a95 in XrdScheduler::Run (this=0x3cf180afc0) at /usr/src/debug/xrootd/xrootd/src/Xrd/XrdScheduler.cc:307
#8  0x0000003cf2652c89 in XrdStartWorking (carg=<value optimized out>) at /usr/src/debug/xrootd/xrootd/src/Xrd/XrdScheduler.cc:84
#9  0x0000003cf26215bf in XrdSysThread_Xeq (myargs=0x1b234d0) at /usr/src/debug/xrootd/xrootd/src/XrdSys/XrdSysPthread.cc:86
#10 0x0000003cefe07851 in start_thread () from /lib64/libpthread.so.0
#11 0x0000003cefae894d in clone () from /lib64/libc.so.6

Whereas the thread holding the mutex is stuck in:

Thread 3 (Thread 0x7fd15ee07700 (LWP 2114)):
#0  0x0000003cefe073f5 in __nptl_setxid () from /lib64/libpthread.so.0
#1  0x0000003cefaadddd in setresuid () from /lib64/libc.so.6
#2  0x0000003cf2620974 in XrdSysPriv::ChangeTo (newuid=0, newgid=0) at /usr/src/debug/xrootd/xrootd/src/XrdSys/XrdSysPriv.cc:214
#3  0x0000003cf2620ff2 in XrdSysPrivGuard::Init (this=0x7fd15ee063e0, uid=0, gid=0) at /usr/src/debug/xrootd/xrootd/src/XrdSys/XrdSysPriv.cc:405
#4  0x00007fd45b0ef950 in XrdSecProtocolkrb5::Authenticate (this=0x7fd15854a440, cred=<value optimized out>, parms=0x7fd15ee06dd8, error=0x7fd15ee06550) at /usr/src/debug/xrootd/xrootd/src/XrdSeckrb5/XrdSecProtocolkrb5.cc:487
#5  0x000000000041f9cb in XrdXrootdProtocol::do_Auth (this=0x7fd25216a550) at /usr/src/debug/xrootd/xrootd/src/XrdXrootd/XrdXrootdXeq.cc:147
#6  0x0000003cf264ebf9 in XrdLink::DoIt (this=0x2769338) at /usr/src/debug/xrootd/xrootd/src/Xrd/XrdLink.cc:442
#7  0x0000003cf2652a95 in XrdScheduler::Run (this=0x3cf180afc0) at /usr/src/debug/xrootd/xrootd/src/Xrd/XrdScheduler.cc:307
#8  0x0000003cf2652c89 in XrdStartWorking (carg=<value optimized out>) at /usr/src/debug/xrootd/xrootd/src/Xrd/XrdScheduler.cc:84
#9  0x0000003cf26215bf in XrdSysThread_Xeq (myargs=0x7fd250904350) at /usr/src/debug/xrootd/xrootd/src/XrdSys/XrdSysPthread.cc:86
#10 0x0000003cefe07851 in start_thread () from /lib64/libpthread.so.0
#11 0x0000003cefae894d in clone () from /lib64/libc.so.6

This only occurs on SLC6.

Invalid response from CERN EOS in new client

Hi,

When testing the new XrdCl against EOS, we get an invalid response from the server (see below). Tests with valgrind / helgrind don't reveal any issues in the client code.

This appears to either be a xrootd server error (or network error, although I'm a bit suspicious because the first four digits of "65798152" are always the same). It happens somewhere between one-in-a-hundred and one-in-a-thousand readv calls.

I do validate that all requests which are sent to the server are in order by offset, have reasonable offsets (0<= offset <1TB), and have reasonable sizes (<512KB).

However, I file this bug because we don't see this issue with XrdClient. Is it possible that this was silently swallowed by the old client?

Brian

Begin processing the 501st record. Run 166462, Event 401746618, LumiSection 390 at 16-Sep-2013 14:45:26.989 CEST
[2013-09-16 14:45:27 +0200][Debug  ][File              ] [0xfd673d80@root://eoscms//eos/cms/store/data/Run2011A/Jet/RAW-RECO/HighMET-08Nov2011-v1/0000/A831F356-520B-E111-ABB9-001D0967DAAD.root?svcClass=default] Sending a vector read command for handle 0x0 to lxfsre46c03.cern.ch:1095
[2013-09-16 14:45:27 +0200][Dump   ][XRootD            ] [lxfsre46c03.cern.ch:1095] Sending message kXR_readv (handle: 0x0000, chunks: 94, total size: 10153030)
[2013-09-16 14:45:27 +0200][Dump   ][PostMaster        ] [lxfsre46c03.cern.ch:1095 #0] Sending message kXR_readv (handle: 0x0000, chunks: 94, total size: 10153030) through substream 0 expecting answer at 0
[2013-09-16 14:45:27 +0200][Dump   ][AsyncSock         ] [lxfsre46c03.cern.ch:1095 #0.0] Wrote a message: kXR_readv (handle: 0x0000, chunks: 94, total size: 10153030), 1528 bytes
[2013-09-16 14:45:27 +0200][Dump   ][AsyncSock         ] [lxfsre46c03.cern.ch:1095 #0.0] successfully sent message: kXR_readv (handle: 0x0000, chunks: 94, total size: 10153030).
[2013-09-16 14:45:27 +0200][Dump   ][XRootD            ] [lxfsre46c03.cern.ch:1095] Message kXR_readv (handle: 0x0000, chunks: 94, total size: 10153030) has been successfully sent.
[2013-09-16 14:45:27 +0200][Dump   ][PostMaster        ] [lxfsre46c03.cern.ch:1095 #0.0] Nothing to write, disable uplink
[2013-09-16 14:45:27 +0200][Dump   ][AsyncSock         ] [lxfsre46c03.cern.ch:1095 #0.0] Received message header, size: 8
[2013-09-16 14:45:27 +0200][Dump   ][XRootD            ] [lxfsre46c03.cern.ch:1095] Got a kXR_oksofar response to request kXR_readv (handle: 0x0000, chunks: 94, total size: 10153030)
[2013-09-16 14:45:27 +0200][Dump   ][AsyncSock         ] [lxfsre46c03.cern.ch:1095 #0.0] Will use the raw handler to read message body.
[2013-09-16 14:45:27 +0200][Dump   ][XRootD            ] [lxfsre46c03.cern.ch:1095] ReadRawReadV: read buffer for chunk 8064@804398311
[2013-09-16 14:45:27 +0200][Dump   ][XRootD            ] [lxfsre46c03.cern.ch:1095] ReadRawReadV: read buffer for chunk 149722@804674969
[2013-09-16 14:45:27 +0200][Dump   ][XRootD            ] [lxfsre46c03.cern.ch:1095] ReadRawReadV: read buffer for chunk 1470824704@5781505023888326656
[2013-09-16 14:45:27 +0200][Error  ][XRootD            ] [lxfsre46c03.cern.ch:1095] ReadRawReadV: Impossible to find chunk buffer corresponding to 65798152 bytes at -5249434835942965143.
[2013-09-16 14:45:27 +0200][Dump   ][XRootD            ] [lxfsre46c03.cern.ch:1095] ReadRawReadV: read buffer for chunk 65798152@-5249434835942965143
[2013-09-16 14:45:27 +0200][Dump   ][AsyncSock         ] [lxfsre46c03.cern.ch:1095 #0.0] Received a message of 1976836 bytes
[2013-09-16 14:45:27 +0200][Dump   ][PostMaster        ] [lxfsre46c03.cern.ch:1095 #0] Handling received message: .
[2013-09-16 14:45:27 +0200][Dump   ][PostMaster        ] [lxfsre46c03.cern.ch:1095 #0] Ignoring the processing handler for: .
[2013-09-16 14:45:27 +0200][Dump   ][AsyncSock         ] [lxfsre46c03.cern.ch:1095 #0.0] Received message header, size: 8
[2013-09-16 14:45:27 +0200][Dump   ][XRootD            ] [lxfsre46c03.cern.ch:1095] Got a kXR_oksofar response to request kXR_readv (handle: 0x0000, chunks: 94, total size: 10153030)
[2013-09-16 14:45:27 +0200][Dump   ][AsyncSock         ] [lxfsre46c03.cern.ch:1095 #0.0] Will use the raw handler to read message body.
[2013-09-16 14:45:27 +0200][Dump   ][XRootD            ] [lxfsre46c03.cern.ch:1095] ReadRawReadV: read buffer for chunk 160940@811124086
[2013-09-16 14:45:27 +0200][Dump   ][XRootD            ] [lxfsre46c03.cern.ch:1095] ReadRawReadV: read buffer for chunk 220731@811285026
[2013-09-16 14:45:27 +0200][Dump   ][XRootD            ] [lxfsre46c03.cern.ch:1095] ReadRawReadV: read buffer for chunk 113@812835267
[2013-09-16 14:45:27 +0200][Dump   ][XRootD            ] [lxfsre46c03.cern.ch:1095] ReadRawReadV: read buffer for chunk 8173@815986832
[2013-09-16 14:45:27 +0200][Dump   ][XRootD            ] [lxfsre46c03.cern.ch:1095] ReadRawReadV: read buffer for chunk 38168@816281545
[2013-09-16 14:45:27 +0200][Dump   ][XRootD            ] [lxfsre46c03.cern.ch:1095] ReadRawReadV: read buffer for chunk 129348@816319713
[2013-09-16 14:45:27 +0200][Dump   ][XRootD            ] [lxfsre46c03.cern.ch:1095] ReadRawReadV: read buffer for chunk 137837@817053233
[2013-09-16 14:45:27 +0200][Dump   ][XRootD            ] [lxfsre46c03.cern.ch:1095] ReadRawReadV: read buffer for chunk 81714@817191070
[2013-09-16 14:45:27 +0200][Dump   ][XRootD            ] [lxfsre46c03.cern.ch:1095] ReadRawReadV: read buffer for chunk 162394@817563758
[2013-09-16 14:45:27 +0200][Dump   ][XRootD            ] [lxfsre46c03.cern.ch:1095] ReadRawReadV: read buffer for chunk 290262@818699658
[2013-09-16 14:45:27 +0200][Dump   ][XRootD            ] [lxfsre46c03.cern.ch:1095] ReadRawReadV: read buffer for chunk 29862@818989920
[2013-09-16 14:45:27 +0200][Dump   ][XRootD            ] [lxfsre46c03.cern.ch:1095] ReadRawReadV: read buffer for chunk 237323@819728240
[2013-09-16 14:45:27 +0200][Dump   ][XRootD            ] [lxfsre46c03.cern.ch:1095] ReadRawReadV: read buffer for chunk 9087@819965563
[2013-09-16 14:45:27 +0200][Dump   ][XRootD            ] [lxfsre46c03.cern.ch:1095] ReadRawReadV: read buffer for chunk 194610@820496977
[2013-09-16 14:45:27 +0200][Dump   ][XRootD            ] [lxfsre46c03.cern.ch:1095] ReadRawReadV: read buffer for chunk 63488@821342192
[2013-09-16 14:45:27 +0200][Dump   ][XRootD            ] [lxfsre46c03.cern.ch:1095] ReadRawReadV: read buffer for chunk 168570@821405680
[2013-09-16 14:45:27 +0200][Dump   ][XRootD            ] [lxfsre46c03.cern.ch:1095] ReadRawReadV: read buffer for chunk 116@821927560
[2013-09-16 14:45:27 +0200][Dump   ][XRootD            ] [lxfsre46c03.cern.ch:1095] ReadRawReadV: read buffer for chunk 98499@822095304
[2013-09-16 14:45:27 +0200][Dump   ][AsyncSock         ] [lxfsre46c03.cern.ch:1095 #0.0] Received a message of 2031531 bytes
[2013-09-16 14:45:27 +0200][Dump   ][PostMaster        ] [lxfsre46c03.cern.ch:1095 #0] Handling received message: .
[2013-09-16 14:45:27 +0200][Dump   ][PostMaster        ] [lxfsre46c03.cern.ch:1095 #0] Ignoring the processing handler for: .
[2013-09-16 14:45:27 +0200][Dump   ][AsyncSock         ] [lxfsre46c03.cern.ch:1095 #0.0] Received message header, size: 8
[2013-09-16 14:45:27 +0200][Dump   ][XRootD            ] [lxfsre46c03.cern.ch:1095] Got a kXR_oksofar response to request kXR_readv (handle: 0x0000, chunks: 94, total size: 10153030)
[2013-09-16 14:45:27 +0200][Dump   ][AsyncSock         ] [lxfsre46c03.cern.ch:1095 #0.0] Will use the raw handler to read message body.
[2013-09-16 14:45:27 +0200][Dump   ][XRootD            ] [lxfsre46c03.cern.ch:1095] ReadRawReadV: read buffer for chunk 263382@822193803
[2013-09-16 14:45:27 +0200][Dump   ][XRootD            ] [lxfsre46c03.cern.ch:1095] ReadRawReadV: read buffer for chunk 270988@822633577
[2013-09-16 14:45:27 +0200][Dump   ][XRootD            ] [lxfsre46c03.cern.ch:1095] ReadRawReadV: read buffer for chunk 23021@822904565
[2013-09-16 14:45:27 +0200][Dump   ][XRootD            ] [lxfsre46c03.cern.ch:1095] ReadRawReadV: read buffer for chunk 181412@823401267
[2013-09-16 14:45:27 +0200][Dump   ][XRootD            ] [lxfsre46c03.cern.ch:1095] ReadRawReadV: read buffer for chunk 62752@824209024
[2013-09-16 14:45:27 +0200][Dump   ][XRootD            ] [lxfsre46c03.cern.ch:1095] ReadRawReadV: read buffer for chunk 199739@824271776
[2013-09-16 14:45:27 +0200][Dump   ][XRootD            ] [lxfsre46c03.cern.ch:1095] ReadRawReadV: read buffer for chunk 115@825852524
[2013-09-16 14:45:27 +0200][Dump   ][XRootD            ] [lxfsre46c03.cern.ch:1095] ReadRawReadV: read buffer for chunk 2843@828309218
[2013-09-16 14:45:27 +0200][Dump   ][XRootD            ] [lxfsre46c03.cern.ch:1095] ReadRawReadV: read buffer for chunk 64488@828656824
[2013-09-16 14:45:27 +0200][Dump   ][XRootD            ] [lxfsre46c03.cern.ch:1095] ReadRawReadV: read buffer for chunk 139624@828721312
[2013-09-16 14:45:27 +0200][Dump   ][XRootD            ] [lxfsre46c03.cern.ch:1095] ReadRawReadV: read buffer for chunk 127561@829660214
[2013-09-16 14:45:27 +0200][Dump   ][XRootD            ] [lxfsre46c03.cern.ch:1095] ReadRawReadV: read buffer for chunk 128305@829787775
[2013-09-16 14:45:27 +0200][Dump   ][XRootD            ] [lxfsre46c03.cern.ch:1095] ReadRawReadV: read buffer for chunk 128107@830094489
[2013-09-16 14:45:27 +0200][Dump   ][XRootD            ] [lxfsre46c03.cern.ch:1095] ReadRawReadV: read buffer for chunk 10773@830694515
[2013-09-16 14:45:27 +0200][Dump   ][XRootD            ] [lxfsre46c03.cern.ch:1095] ReadRawReadV: read buffer for chunk 201989@830705288
[2013-09-16 14:45:27 +0200][Dump   ][XRootD            ] [lxfsre46c03.cern.ch:1095] ReadRawReadV: read buffer for chunk 65196@831655893
[2013-09-16 14:45:27 +0200][Dump   ][XRootD            ] [lxfsre46c03.cern.ch:1095] ReadRawReadV: read buffer for chunk 176400@831721089
[2013-09-16 14:45:27 +0200][Dump   ][XRootD            ] [lxfsre46c03.cern.ch:1095] ReadRawReadV: read buffer for chunk 114@832183032
[2013-09-16 14:45:27 +0200][Dump   ][XRootD            ] [lxfsre46c03.cern.ch:1095] ReadRawReadV: read buffer for chunk 11568@834551869
[2013-09-16 14:45:27 +0200][Dump   ][AsyncSock         ] [lxfsre46c03.cern.ch:1095 #0.0] Received a message of 2058689 bytes
[2013-09-16 14:45:27 +0200][Dump   ][PostMaster        ] [lxfsre46c03.cern.ch:1095 #0] Handling received message: .
[2013-09-16 14:45:27 +0200][Dump   ][PostMaster        ] [lxfsre46c03.cern.ch:1095 #0] Ignoring the processing handler for: .
[2013-09-16 14:45:27 +0200][Dump   ][AsyncSock         ] [lxfsre46c03.cern.ch:1095 #0.0] Received message header, size: 8
[2013-09-16 14:45:27 +0200][Dump   ][XRootD            ] [lxfsre46c03.cern.ch:1095] Got a kXR_oksofar response to request kXR_readv (handle: 0x0000, chunks: 94, total size: 10153030)
[2013-09-16 14:45:27 +0200][Dump   ][AsyncSock         ] [lxfsre46c03.cern.ch:1095 #0.0] Will use the raw handler to read message body.
[2013-09-16 14:45:27 +0200][Dump   ][XRootD            ] [lxfsre46c03.cern.ch:1095] ReadRawReadV: read buffer for chunk 79103@835345078
[2013-09-16 14:45:27 +0200][Dump   ][XRootD            ] [lxfsre46c03.cern.ch:1095] ReadRawReadV: read buffer for chunk 207442@835424181
[2013-09-16 14:45:27 +0200][Dump   ][XRootD            ] [lxfsre46c03.cern.ch:1095] ReadRawReadV: read buffer for chunk 59743@836169473
[2013-09-16 14:45:27 +0200][Dump   ][XRootD            ] [lxfsre46c03.cern.ch:1095] ReadRawReadV: read buffer for chunk 144021@836229216
[2013-09-16 14:45:27 +0200][Dump   ][XRootD            ] [lxfsre46c03.cern.ch:1095] ReadRawReadV: read buffer for chunk 123164@836677521
[2013-09-16 14:45:27 +0200][Dump   ][XRootD            ] [lxfsre46c03.cern.ch:1095] ReadRawReadV: read buffer for chunk 26414@836800685
[2013-09-16 14:45:27 +0200][Dump   ][XRootD            ] [lxfsre46c03.cern.ch:1095] ReadRawReadV: read buffer for chunk 173513@837323436
[2013-09-16 14:45:27 +0200][Dump   ][XRootD            ] [lxfsre46c03.cern.ch:1095] ReadRawReadV: read buffer for chunk 67258@837737443
[2013-09-16 14:45:27 +0200][Dump   ][XRootD            ] [lxfsre46c03.cern.ch:1095] ReadRawReadV: read buffer for chunk 86604@837804701
[2013-09-16 14:45:27 +0200][Dump   ][XRootD            ] [lxfsre46c03.cern.ch:1095] ReadRawReadV: read buffer for chunk 180581@838412309
[2013-09-16 14:45:27 +0200][Dump   ][XRootD            ] [lxfsre46c03.cern.ch:1095] ReadRawReadV: read buffer for chunk 19459@838592890
[2013-09-16 14:45:27 +0200][Dump   ][XRootD            ] [lxfsre46c03.cern.ch:1095] ReadRawReadV: read buffer for chunk 144750@838827824
[2013-09-16 14:45:27 +0200][Dump   ][XRootD            ] [lxfsre46c03.cern.ch:1095] ReadRawReadV: read buffer for chunk 102976@839588475
[2013-09-16 14:45:27 +0200][Dump   ][XRootD            ] [lxfsre46c03.cern.ch:1095] ReadRawReadV: read buffer for chunk 108085@839691451
[2013-09-16 14:45:27 +0200][Dump   ][XRootD            ] [lxfsre46c03.cern.ch:1095] ReadRawReadV: read buffer for chunk 159100@840121145
[2013-09-16 14:45:27 +0200][Dump   ][XRootD            ] [lxfsre46c03.cern.ch:1095] ReadRawReadV: read buffer for chunk 36141@840280245
[2013-09-16 14:45:27 +0200][Dump   ][XRootD            ] [lxfsre46c03.cern.ch:1095] ReadRawReadV: read buffer for chunk 189219@840609610
[2013-09-16 14:45:27 +0200][Dump   ][XRootD            ] [lxfsre46c03.cern.ch:1095] ReadRawReadV: read buffer for chunk 41825@840857400
[2013-09-16 14:45:27 +0200][Dump   ][AsyncSock         ] [lxfsre46c03.cern.ch:1095 #0.0] Received a message of 1949694 bytes
[2013-09-16 14:45:27 +0200][Dump   ][PostMaster        ] [lxfsre46c03.cern.ch:1095 #0] Handling received message: .
[2013-09-16 14:45:27 +0200][Dump   ][PostMaster        ] [lxfsre46c03.cern.ch:1095 #0] Ignoring the processing handler for: .
[2013-09-16 14:45:27 +0200][Dump   ][AsyncSock         ] [lxfsre46c03.cern.ch:1095 #0.0] Received message header, size: 8
[2013-09-16 14:45:27 +0200][Dump   ][XRootD            ] [lxfsre46c03.cern.ch:1095] Got a kXR_oksofar response to request kXR_readv (handle: 0x0000, chunks: 94, total size: 10153030)
[2013-09-16 14:45:27 +0200][Dump   ][AsyncSock         ] [lxfsre46c03.cern.ch:1095 #0.0] Will use the raw handler to read message body.
[2013-09-16 14:45:27 +0200][Dump   ][XRootD            ] [lxfsre46c03.cern.ch:1095] ReadRawReadV: read buffer for chunk 154779@840899225
[2013-09-16 14:45:27 +0200][Dump   ][XRootD            ] [lxfsre46c03.cern.ch:1095] ReadRawReadV: read buffer for chunk 112@842183192
[2013-09-16 14:45:27 +0200][Dump   ][XRootD            ] [lxfsre46c03.cern.ch:1095] ReadRawReadV: read buffer for chunk 1517@844888865
[2013-09-16 14:45:27 +0200][Dump   ][XRootD            ] [lxfsre46c03.cern.ch:1095] ReadRawReadV: read buffer for chunk 7574@844990771
[2013-09-16 14:45:27 +0200][Dump   ][XRootD            ] [lxfsre46c03.cern.ch:1095] ReadRawReadV: read buffer for chunk 103203@845539118
[2013-09-16 14:45:27 +0200][Dump   ][XRootD            ] [lxfsre46c03.cern.ch:1095] ReadRawReadV: read buffer for chunk 144432@845642321
[2013-09-16 14:45:27 +0200][Dump   ][XRootD            ] [lxfsre46c03.cern.ch:1095] ReadRawReadV: read buffer for chunk 122753@846388555
[2013-09-16 14:45:27 +0200][Dump   ][XRootD            ] [lxfsre46c03.cern.ch:1095] ReadRawReadV: read buffer for chunk 87392@846511308
[2013-09-16 14:45:27 +0200][Dump   ][XRootD            ] [lxfsre46c03.cern.ch:1095] ReadRawReadV: read buffer for chunk 179793@847255132
[2013-09-16 14:45:27 +0200][Dump   ][XRootD            ] [lxfsre46c03.cern.ch:1095] ReadRawReadV: read buffer for chunk 47878@847434925
[2013-09-16 14:45:27 +0200][Dump   ][XRootD            ] [lxfsre46c03.cern.ch:1095] ReadRawReadV: read buffer for chunk 219307@848312568
[2013-09-16 14:45:27 +0200][Dump   ][XRootD            ] [lxfsre46c03.cern.ch:1095] ReadRawReadV: read buffer for chunk 32188@848531875
[2013-09-16 14:45:27 +0200][Dump   ][XRootD            ] [lxfsre46c03.cern.ch:1095] ReadRawReadV: read buffer for chunk 232922@849089971
[2013-09-16 14:45:27 +0200][Dump   ][XRootD            ] [lxfsre46c03.cern.ch:1095] ReadRawReadV: read buffer for chunk 2075@849501538
[2013-09-16 14:45:27 +0200][Dump   ][XRootD            ] [lxfsre46c03.cern.ch:1095] ReadRawReadV: read buffer for chunk 125710@849503613
[2013-09-16 14:45:27 +0200][Dump   ][XRootD            ] [lxfsre46c03.cern.ch:1095] ReadRawReadV: read buffer for chunk 141475@850302643
[2013-09-16 14:45:27 +0200][Dump   ][XRootD            ] [lxfsre46c03.cern.ch:1095] ReadRawReadV: read buffer for chunk 86234@850444118
[2013-09-16 14:45:27 +0200][Dump   ][XRootD            ] [lxfsre46c03.cern.ch:1095] ReadRawReadV: read buffer for chunk 116@850884493
[2013-09-16 14:45:27 +0200][Dump   ][XRootD            ] [lxfsre46c03.cern.ch:1095] ReadRawReadV: read buffer for chunk 180835@851117007
[2013-09-16 14:45:27 +0200][Dump   ][XRootD            ] [lxfsre46c03.cern.ch:1095] ReadRawReadV: read buffer for chunk 83749@851297842
[2013-09-16 14:45:27 +0200][Dump   ][AsyncSock         ] [lxfsre46c03.cern.ch:1095 #0.0] Received a message of 1954372 bytes
[2013-09-16 14:45:27 +0200][Dump   ][PostMaster        ] [lxfsre46c03.cern.ch:1095 #0] Handling received message: .
[2013-09-16 14:45:27 +0200][Dump   ][PostMaster        ] [lxfsre46c03.cern.ch:1095 #0] Ignoring the processing handler for: .
[2013-09-16 14:45:27 +0200][Dump   ][AsyncSock         ] [lxfsre46c03.cern.ch:1095 #0.0] Received message header, size: 8
[2013-09-16 14:45:27 +0200][Dump   ][AsyncSock         ] [lxfsre46c03.cern.ch:1095 #0.0] Will use the raw handler to read message body.
[2013-09-16 14:45:27 +0200][Dump   ][XRootD            ] [lxfsre46c03.cern.ch:1095] ReadRawReadV: read buffer for chunk 183436@851524651
[2013-09-16 14:45:27 +0200][Dump   ][AsyncSock         ] [lxfsre46c03.cern.ch:1095 #0.0] Received a message of 183460 bytes
[2013-09-16 14:45:27 +0200][Dump   ][PostMaster        ] [lxfsre46c03.cern.ch:1095 #0] Handling received message: .
[2013-09-16 14:45:27 +0200][Dump   ][XRootD            ] [lxfsre46c03.cern.ch:1095] Got a kXR_ok response to request kXR_readv (handle: 0x0000, chunks: 94, total size: 10153030)
[2013-09-16 14:45:27 +0200][Dump   ][XRootD            ] [lxfsre46c03.cern.ch:1095] Parsing the response to 0x15347238 as VectorReadInfo
[2013-09-16 14:45:27 +0200][Dump   ][File              ] [0xfd673d80@root://eoscms//eos/cms/store/data/Run2011A/Jet/RAW-RECO/HighMET-08Nov2011-v1/0000/A831F356-520B-E111-ABB9-001D0967DAAD.root?svcClass=default] File state error encountered. Message kXR_readv (handle: 0x0000, chunks: 94, total size: 10153030) returned with [FATAL] Invalid response
[2013-09-16 14:45:27 +0200][Error  ][File              ] [0xfd673d80@root://eoscms//eos/cms/store/data/Run2011A/Jet/RAW-RECO/HighMET-08Nov2011-v1/0000/A831F356-520B-E111-ABB9-001D0967DAAD.root?svcClass=default] Fatal file state error. Message kXR_readv (handle: 0x0000, chunks: 94, total size: 10153030) returned with [FATAL] Invalid response
[2013-09-16 14:45:27 +0200][Dump   ][File              ] [0xfd673d80@root://eoscms//eos/cms/store/data/Run2011A/Jet/RAW-RECO/HighMET-08Nov2011-v1/0000/A831F356-520B-E111-ABB9-001D0967DAAD.root?svcClass=default] Failing message kXR_readv (handle: 0x0000, chunks: 94, total size: 10153030) with [FATAL] Invalid response
%MSG-w XrdAdaptorInternal:  (NoModuleName) 16-Sep-2013 14:45:27 CEST pre-events
XrdRequestManager::handle(name='root://eoscms//eos/cms/store/data/Run2011A/Jet/RAW-RECO/HighMET-08Nov2011-v1/0000/A831F356-520B-E111-ABB9-001D0967DAAD.root?svcClass=default) failure when reading from lxfsre46c03.cern.ch:1095; failed with error '[FATAL] Invalid response' (errno=0, code=303).
%MSG
[2013-09-16 14:45:31 +0200][Dump   ][TaskMgr           ] Running task: "TickGeneratorTask for: eoscms:1094"
[2013-09-16 14:45:31 +0200][Dump   ][TaskMgr           ] Will rerun task "TickGeneratorTask for: eoscms:1094" at [2013-09-16 14:45:46 +0200]
[2013-09-16 14:45:31 +0200][Dump   ][TaskMgr           ] Running task: "FileTimer task"

The old client fork handlers hang in XrdClientSock::RecvRaw

The fork handlers will hang in XrdClientSock::RecvRaw as it does not seem to honor disconnections (XrdClientSock::Disconnect) and blocks in poll.

Thread 2 (Thread 0x7f092958e700 (LWP 16558)):
#0  0x000000331f0df293 in poll () from /lib64/libc.so.6
#1  0x00007f092a779e74 in XrdClientSock::RecvRaw(void*, int, int, int*) () from /usr//lib64/libXrdClient.so.1
#2  0x00007f092a79b98f in XrdClientPhyConnection::ReadRaw(void*, int, int, int*) () from /usr//lib64/libXrdClient.so.1
#3  0x00007f092a79e053 in XrdClientMessage::ReadRaw(XrdClientPhyConnection*) () from /usr//lib64/libXrdClient.so.1
#4  0x00007f092a799d58 in XrdClientPhyConnection::BuildMessage(bool, bool) () from /usr//lib64/libXrdClient.so.1
#5  0x00007f092a79d26a in SocketReaderThread(void*, XrdClientThread*) () from /usr//lib64/libXrdClient.so.1
#6  0x00007f092aa110af in XrdSysThread_Xeq () from /usr//lib64/libXrdUtils.so.1
#7  0x000000331fc07851 in start_thread () from /lib64/libpthread.so.0
#8  0x000000331f0e894d in clone () from /lib64/libc.so.6

Thread 1 (Thread 0x7f092a756760 (LWP 16556)):
#0  0x000000331fc080ad in pthread_join () from /lib64/libpthread.so.0
#1  0x00007f092a79b04d in XrdClientPhyConnection::~XrdClientPhyConnection() () from /usr//lib64/libXrdClient.so.1
#2  0x00007f092a79b329 in XrdClientPhyConnection::~XrdClientPhyConnection() () from /usr//lib64/libXrdClient.so.1
#3  0x00007f092a79141a in DestroyPhyConn(char const*, XrdClientPhyConnection*, void*) () from /usr//lib64/libXrdClient.so.1
#4  0x00007f092a79604e in XrdOucHash<XrdClientPhyConnection>::Apply(int (*)(char const*, XrdClientPhyConnection*, void*), void*) () from /usr//lib64/libXrdClient.so.1
#5  0x00007f092a79290a in XrdClientConnectionMgr::ShutDown() () from /usr//lib64/libXrdClient.so.1
#6  0x00007f092a7b3083 in ?? () from /usr//lib64/libXrdClient.so.1
#7  0x000000331f0acc55 in fork () from /lib64/libc.so.6
#8  0x0000000000409041 in XrdStress::RunTestProcesses (this=0x2107790) at /home/esindril/Programs/eos/test/XrdStress.cc:267
#9  0x0000000000408e92 in XrdStress::RunTest (this=0x2107790) at /home/esindril/Programs/eos/test/XrdStress.cc:221
#10 0x000000000040b7aa in main (argc=15, argv=0x7fffba37ca18) at /home/esindril/Programs/eos/test/XrdStress.cc:902

repository numbering differences between osg and xrootd causing problems

Hi,

Here is an issue that I have seen due to the repository miss match xrootd - osg - epel.

I am including the text of the OSG ticket that I filed.

https://ticket.grid.iu.edu/goc/14976

Hello,

Today we saw these yum errors due to repository incompatibilities - osg vs xrootd for the xrootd software -

YUM - security

1:xrootd-client-libs-3.3.1-1.2.osg.el5.x86_64 from osg has depsolving problems   --> Missing Dependency: xrootd-libs = 1:3.3.1-1.2.osg.el5 is needed by
package 1:xrootd-client-libs-3.3.1-1.2.osg.el5.x86_64 (osg)

1:xrootd-server-libs-3.3.1-1.2.osg.el5.x86_64 from osg has depsolving problems   --> Missing Dependency: xrootd-libs = 1:3.3.1-1.2.osg.el5 is needed by
package 1:xrootd-server-libs-3.3.1-1.2.osg.el5.x86_64 (osg)

1:xrootd-3.3.1-1.2.osg.el5.x86_64 from osg has depsolving problems   --> Missing Dependency: xrootd-libs = 1:3.3.1-1.2.osg.el5 is needed by
package 1:xrootd-3.3.1-1.2.osg.el5.x86_64 (osg)

1:xrootd-server-devel-3.3.1-1.slc5.xu.x86_64 from installed has depsolving problems   --> Missing Dependency: xrootd-libs-devel = 1:3.3.1-1.slc5.xu is
needed by package 1:xrootd-server-devel-3.3.1-1.slc5.xu.x86_64 (installed)

1:xrootd-client-devel-3.3.1-1.slc5.xu.x86_64 from installed has depsolving problems   --> Missing Dependency: xrootd-libs-devel = 1:3.3.1-1.slc5.xu is
needed by package 1:xrootd-client-devel-3.3.1-1.slc5.xu.x86_64 (installed)

1:xrootd-devel-3.3.1-1.2.osg.el5.x86_64 from osg has depsolving problems   --> Missing Dependency: xrootd-libs = 1:3.3.1-1.2.osg.el5 is needed by
package 1:xrootd-devel-3.3.1-1.2.osg.el5.x86_64 (osg)

1:xrootd-server-devel-3.3.1-1.slc5.xu.x86_64 from installed has depsolving problems   --> Missing Dependency: xrootd-server = 1:3.3.1-1.slc5.xu is needed by
package 1:xrootd-server-devel-3.3.1-1.slc5.xu.x86_64 (installed)

Error: Missing Dependency: xrootd-libs = 1:3.3.1-1.2.osg.el5 is needed by package 1:xrootd-devel-3.3.1-1.2.osg.el5.x86_64 (osg)
Error: Missing Dependency: xrootd-libs-devel = 1:3.3.1-1.slc5.xu is needed by package 1:xrootd-server-devel-3.3.1-1.slc5.xu.x86_64 (installed)
Error: Missing Dependency: xrootd-libs = 1:3.3.1-1.2.osg.el5 is needed by package 1:xrootd-client-libs-3.3.1-1.2.osg.el5.x86_64 (osg)
Error: Missing Dependency: xrootd-libs = 1:3.3.1-1.2.osg.el5 is needed by package 1:xrootd-server-libs-3.3.1-1.2.osg.el5.x86_64 (osg)
Error: Missing Dependency: xrootd-libs = 1:3.3.1-1.2.osg.el5 is needed by package 1:xrootd-3.3.1-1.2.osg.el5.x86_64 (osg)
Error: Missing Dependency: xrootd-server = 1:3.3.1-1.slc5.xu is needed by package 1:xrootd-server-devel-3.3.1-1.slc5.xu.x86_64 (installed)
Error: Missing Dependency: xrootd-libs-devel = 1:3.3.1-1.slc5.xu is needed by package 1:xrootd-client-devel-3.3.1-1.slc5.xu.x86_64 (installed)

Here is what is installed on the machine

Installed Packages
xrootd-cl.x86_64                                                            1:3.3.1-1.slc5.xu                                                installed    
xrootd-client.x86_64                                                        1:3.3.1-1.slc5.xu                                                installed    
xrootd-client-devel.x86_64                                                  1:3.3.1-1.slc5.xu                                                installed    
xrootd-debuginfo.x86_64                                                     1:3.3.1-1.slc5.xu                                                installed    
xrootd-dsi.x86_64                                                           3.0.4-10.osg.el5                                                 installed    
xrootd-fuse.x86_64                                                          1:3.3.1-1.slc5.xu                                                installed    
xrootd-libs.x86_64                                                          1:3.3.1-1.slc5.xu                                                installed    
xrootd-libs-devel.x86_64                                                    1:3.3.1-1.slc5.xu                                                installed    
xrootd-server.x86_64                                                        1:3.3.1-1.slc5.xu                                                installed    
xrootd-server-devel.x86_64                                                  1:3.3.1-1.slc5.xu                                                installed

We have yum priorities installed
the xrootd repo has priority 50
osg priority 98
epel priority 99

Do you think that things could be better aligned? Especially in the rpm numbering and rpm's. This clear has caused at least one site problems.

External xrd/xrdfs directory listing slow (request for bulk query possibility)

Hi,

When listing CASTOR directories using xrd/xrdfs the operation takes about 10ms per file and gets really slow in case of large directories (10mins for 10kfiles). Some experiments are moving to xrootd framework and want to have xroot command that work efficiently on different systems (say CASTOR and EOS). So the question is if bulk request can be implemented at xrootd server side to send a bulk of files to CASTOR so the per file 'stat' ping-pong can be avoided.

Many thanks in advance.
Xavi.

Compilation errors with clang 3.2

In file included from /home/ljanyst/Projects/xroot/client/repo/xrootd/src/XrdOfs/XrdOfsTPCAuth.cc:36:
/home/ljanyst/Projects/xroot/client/repo/xrootd/src/./XrdOfs/XrdOfsTPCAuth.hh:39:17: warning: using directive refers to implicitly-defined namespace 'std'
using namespace std;
                ^
/home/ljanyst/Projects/xroot/client/repo/xrootd/src/XrdOfs/XrdOfsTPC.cc:40:
/home/ljanyst/Projects/xroot/client/repo/xrootd/src/./XrdOfs/XrdOfsTPCAuth.hh:39:17: warning: using directive refers to implicitly-defined namespace 'std'
using namespace std;
                ^

/home/ljanyst/Projects/xroot/client/repo/xrootd/src/XrdPosix/XrdPosixPreload32.cc:491:26: warning: 'memset' call operates on objects of type 'struct statfs' while the size is based on a different type 'struct statfs *' [-Wsizeof-pointer-memaccess]
   memset(buf, 0, sizeof(buf));
          ~~~            ^~~
/home/ljanyst/Projects/xroot/client/repo/xrootd/src/XrdPosix/XrdPosixPreload32.cc:491:26: note: did you mean to dereference the argument to 'sizeof' (and multiply it by the number of elements)?
   memset(buf, 0, sizeof(buf));
                         ^~~
/home/ljanyst/Projects/xroot/client/repo/xrootd/src/XrdPosix/XrdPosixPreload32.cc:518:26: warning: 'memset' call operates on objects of type 'struct statvfs' while the size is based on a different type 'struct statvfs *' [-Wsizeof-pointer-memaccess]
   memset(buf, 0, sizeof(buf));
          ~~~            ^~~
/home/ljanyst/Projects/xroot/client/repo/xrootd/src/XrdPosix/XrdPosixPreload32.cc:518:26: note: did you mean to dereference the argument to 'sizeof' (and multiply it by the number of elements)?
   memset(buf, 0, sizeof(buf));
                         ^~~

OSS WriteV calls Read

In XrdOss.hh:106 the default implementation of WriteV should call the "Write" method and not "Read". I know its overridden in XrdOssApi but just for correctness.

xrootd-client not sending opaque info on recovered connection

It seems that the xrootd client after recovering a connection to a server don't send anymore the opaque information. This behavior make all the "shaky" transfers aborting.
We experience the issue with both xrootd client 3.2.7-1 and 3.3.3-1

xrdcp -f -np -d 1 root://lxbrf39c03.cern.ch//eos/.../file.root /dev/null
[...]
130823 14:39:31 20129 Xrd: Open: Access to server granted.
130823 14:39:31 20129 Xrd: Open: Opening the remote file /eos/.../file.root
130823 14:39:31 20129 Xrd: Open: File open in progress.
130823 14:39:31 20132 Xrd: HandleServerError: Received redirection to [lxfsre05a07.cern.ch:1095]. Token=[]]. Opaque=[&cap.sym=...&mgm.logid=...2&mgm.blockchecksum=ignore&mgm.replicaindex=3&mgm.replicahead=3].
[...]
130823 14:44:59 20141 Xrd: ReadPartialAnswer: Failed to read msg from connmgr (server [lxfsre05a07.cern.ch:1095]). Retrying ...
130823 14:44:59 20141 Xrd: HandleServerError: Communication error with server [lxfsre05a07.cern.ch:1095]. Rebouncing here.
130823 14:44:59 20141 Xrd: HandleServerError: Received redirection to [lxfsre05a07.cern.ch:1095]. Token=[]]. Opaque=[].
sec_Client: protocol request for host lxfsre05a07.cern.ch token='&P=unix&P=sss,0.13:/etc/eos.keytab'
sec_PM: Using unix protocol, args=''
130823 14:44:59 20141 Xrd: CheckErrorStatus: Server [lxfsre05a07.cern.ch:1095] requested 4 seconds of wait. Server message is session still active
130823 14:45:03 20133 Xrd: XrdClientMessage::ReadRaw: Failed to read data (2097152 bytes) from substream 0.
130823 14:45:03 20141 Xrd: CheckErrorStatus: Server [lxfsre05a07.cern.ch:1095] declared: Unable to open - capability illegal /eos/.../file.root; Invalid argument(error code: 3005)
130823 14:45:03 20141 Xrd: OpenFileWhenRedirected: File open failed.
xrdcp: Copy from lxfsre05a07.cern.ch failed on read!

[XrdCl]

xrootd --version segmentation fault

This happens with v.3.3.2

Infinite poller (error) loop

We observe the following problem with xrootd 3.3.2:

130527 10:20:50 29232 XrootdXeq: daemon.17349:63@lxfssl4102 login as daemon
[..some time..]]
130527 11:55:13 4686 XrdPoll: Sever event occured for daemon.17349:63@lxfssl4102
130527 11:55:13 9327 XrootdXeq: daemon.17349:63@lxfssl4102 disc 1:34:23 (socket error)
130527 11:55:13 4686 XrdPoll: Sever event occured for daemon.17349:63@lxfssl4102
130527 11:55:13 4686 XrdPoll: Unable to exclude link daemon.17349:63@lxfssl4102; no such file or directory
130527 11:55:13 4686 XrdPoll: Sever event occured for daemon.17349:63@lxfssl4102
130527 11:55:13 4686 XrdPoll: Unable to exclude link daemon.17349:63@lxfssl4102; bad file descriptor
130527 11:55:13 4686 XrdPoll: Sever event occured for daemon.17349:63@lxfssl4102
130527 11:55:13 4686 XrdPoll: Unable to exclude link daemon.17349:63@lxfssl4102; bad file descriptor
130527 11:55:13 4686 XrdPoll: Sever event occured for daemon.17349:63@lxfssl4102

Once this happens the XRootd server spit's out in a tight loop the same error message until the disk is filled up from the logfile ...

Built-in poller deadlock

It looks like the built-in poller is deadlocking in:

XrdSys::IOEvents::Channel::Enable vs XrdSys::IOEvents::Poller::CbkTMO. In threads 26 and 24.

Thread 26 (Thread 0x40304940 (LWP 17344)):
#0  0x0000003da6a0d524 in __lll_lock_wait () from /lib64/libpthread.so.0
#1  0x0000003da6a08e35 in _L_lock_1127 () from /lib64/libpthread.so.0
#2  0x0000003da6a08d33 in pthread_mutex_lock () from /lib64/libpthread.so.0
#3  0x000000326f222637 in Lock (this=0x2aaaae41d180, cP=0x2aaaacf4f200, events=<value optimized out>, eNum=0, eTxt=0x0) at /usr/src/debug/xrootd/xrootd/src/XrdSys/XrdSysPthread.hh:149
#4  Lock (this=0x2aaaae41d180, cP=0x2aaaacf4f200, events=<value optimized out>, eNum=0, eTxt=0x0) at /usr/src/debug/xrootd/xrootd/src/XrdSys/XrdSysPthread.hh:197
#5  XrdSys::IOEvents::Poller::CbkXeq (this=0x2aaaae41d180, cP=0x2aaaacf4f200, events=<value optimized out>, eNum=0, eTxt=0x0) at /usr/src/debug/xrootd/xrootd/src/XrdSys/XrdSysIOEvents.cc:626
#6  0x000000326f22286c in XrdSys::IOEvents::Poller::CbkTMO (this=0x2aaaae41d180) at /usr/src/debug/xrootd/xrootd/src/XrdSys/XrdSysIOEvents.cc:548
#7  0x000000326f2229bb in XrdSys::IOEvents::PollE::Begin (this=0x2aaaae41d180, syncsem=<value optimized out>, retcode=<value optimized out>, eTxt=<value optimized out>)
    at /usr/src/debug/xrootd/xrootd/src/XrdSys/XrdSysIOEventsPollE.icc:202
#8  0x000000326f221aa4 in XrdSys::IOEvents::BootStrap::Start (parg=0x40e802b0) at /usr/src/debug/xrootd/xrootd/src/XrdSys/XrdSysIOEvents.cc:110
#9  0x000000326f21fc2f in XrdSysThread_Xeq (myargs=<value optimized out>) at /usr/src/debug/xrootd/xrootd/src/XrdSys/XrdSysPthread.cc:86
#10 0x0000003da6a0673d in start_thread () from /lib64/libpthread.so.0
#11 0x0000003da62d44bd in clone () from /lib64/libc.so.6

Thread 25 (Thread 0x42738940 (LWP 17345)):
#0  0x0000003da6a0d524 in __lll_lock_wait () from /lib64/libpthread.so.0
#1  0x0000003da6a08e35 in _L_lock_1127 () from /lib64/libpthread.so.0
#2  0x0000003da6a08d33 in pthread_mutex_lock () from /lib64/libpthread.so.0
#3  0x00002aaaad668394 in Lock (this=0x2aaaacf94140, now=128) at /usr/src/debug/xrootd/xrootd/src/XrdSys/XrdSysPthread.hh:149
#4  XrdCl::Stream::Tick (this=0x2aaaacf94140, now=128) at /usr/src/debug/xrootd/xrootd/src/XrdCl/XrdClStream.cc:310
#5  0x00002aaaad665f2f in XrdCl::Channel::Tick (this=<value optimized out>, now=1365673017) at /usr/src/debug/xrootd/xrootd/src/XrdCl/XrdClChannel.cc:303
#6  0x00002aaaad666acf in (anonymous namespace)::TickGeneratorTask::Run (this=<value optimized out>, now=128) at /usr/src/debug/xrootd/xrootd/src/XrdCl/XrdClChannel.cc:171
#7  0x00002aaaad671d50 in XrdCl::TaskManager::RunTasks (this=0x2aaaae41d0c0) at /usr/src/debug/xrootd/xrootd/src/XrdCl/XrdClTaskManager.cc:216
#8  0x00002aaaad671e59 in RunRunnerThread (arg=0x2aaaacf94170) at /usr/src/debug/xrootd/xrootd/src/XrdCl/XrdClTaskManager.cc:36
---Type <return> to continue, or q <return> to quit---
#9  0x0000003da6a0673d in start_thread () from /lib64/libpthread.so.0
#10 0x0000003da62d44bd in clone () from /lib64/libc.so.6

Thread 24 (Thread 0x41b3d940 (LWP 17368)):
#0  0x0000003da6a0d524 in __lll_lock_wait () from /lib64/libpthread.so.0
#1  0x0000003da6a08e35 in _L_lock_1127 () from /lib64/libpthread.so.0
#2  0x0000003da6a08d33 in pthread_mutex_lock () from /lib64/libpthread.so.0
#3  0x000000326f22211c in Lock (this=0x2aaaae41d180, cP=0x80) at /usr/src/debug/xrootd/xrootd/src/XrdSys/XrdSysPthread.hh:149
#4  XrdSysMutexHelper (this=0x2aaaae41d180, cP=0x80) at /usr/src/debug/xrootd/xrootd/src/XrdSys/XrdSysPthread.hh:208
#5  XrdSys::IOEvents::Poller::TmoAdd (this=0x2aaaae41d180, cP=0x80) at /usr/src/debug/xrootd/xrootd/src/XrdSys/XrdSysIOEvents.cc:965
#6  0x000000326f22300a in XrdSys::IOEvents::Channel::Enable (this=0x2aaaacf4f200, events=<value optimized out>, timeout=1, eText=0x41b3c768)
    at /usr/src/debug/xrootd/xrootd/src/XrdSys/XrdSysIOEvents.cc:373
#7  0x00002aaaad663293 in XrdCl::PollerBuiltIn::EnableWriteNotification (this=<value optimized out>, socket=0x2aaaacf99190, notify=<value optimized out>, timeout=1)
    at /usr/src/debug/xrootd/xrootd/src/XrdCl/XrdClPollerBuiltIn.cc:404
#8  0x00002aaaad669423 in EnableUplink (this=0x2aaaacf94140, path=...) at /usr/src/debug/xrootd/xrootd/src/XrdCl/XrdClAsyncSocketHandler.hh:96
#9  XrdCl::Stream::EnableLink (this=0x2aaaacf94140, path=...) at /usr/src/debug/xrootd/xrootd/src/XrdCl/XrdClStream.cc:186
#10 0x00002aaaad669729 in XrdCl::Stream::Send (this=0x2aaaacf94140, msg=0x2aaaaf3dee20, handler=0x2aaaaf13ff08, stateful=true, expires=1365673317)
    at /usr/src/debug/xrootd/xrootd/src/XrdCl/XrdClStream.cc:273
#11 0x00002aaaad665ede in XrdCl::Channel::Send (this=0x2aaaac1edec0, msg=0x2aaaaf3dee20, handler=0x2aaaaf13ff08, stateful=true, expires=1365673317)
    at /usr/src/debug/xrootd/xrootd/src/XrdCl/XrdClChannel.cc:266
#12 0x00002aaaad66539e in XrdCl::PostMaster::Send (this=<value optimized out>, url=<value optimized out>, msg=0x2aaaaf3dee20, handler=0x2aaaaf13ff08, stateful=true, expires=1365673317)
    at /usr/src/debug/xrootd/xrootd/src/XrdCl/XrdClPostMaster.cc:169
#13 0x00002aaaad684f10 in XrdCl::MessageUtils::SendMessage (url=..., msg=0x2aaaaf3dee20, handler=<value optimized out>, sendParams=...) at /usr/src/debug/xrootd/xrootd/src/XrdCl/XrdClMessageUtils.cc:109
#14 0x00002aaaad68e836 in XrdCl::FileStateHandler::SendOrQueue (this=0x2aaaac1ed600, url=<value optimized out>, msg=0x2aaaaf3dee20, handler=0x2aaaaf02d9e0, sendParams=...)
    at /usr/src/debug/xrootd/xrootd/src/XrdCl/XrdClFileStateHandler.cc:1129
#15 0x00002aaaad690716 in XrdCl::FileStateHandler::Stat (this=0x2aaaac1ed600, force=<value optimized out>, handler=0x41b3cf00, timeout=0)
    at /usr/src/debug/xrootd/xrootd/src/XrdCl/XrdClFileStateHandler.cc:496
#16 0x00002aaaad687904 in XrdCl::File::Stat (this=<value optimized out>, force=false, handler=0xffffffffffffffff, timeout=53752) at /usr/src/debug/xrootd/xrootd/src/XrdCl/XrdClFile.cc:103
#17 0x00002aaaad68858e in XrdCl::File::Stat (this=0x2aaaac388810, force=true, response=@0x41b3d020, timeout=0) at /usr/src/debug/xrootd/xrootd/src/XrdCl/XrdClFile.cc:114
#18 0x00002aaaad2db2e9 in XrdMqClient::RecvMessage (this=0x2aaaad62ce60) at /afs/cern.ch/work/a/apeters/eos-master/eos/mq/XrdMqClient.cc:304
#19 0x00002aaaad083f58 in eos::mgm::Messaging::Listen (this=0x2aaaac1c9600) at /afs/cern.ch/work/a/apeters/eos-master/eos/mgm/Messaging.cc:185
#20 0x00002aaaad2e1669 in XrdMqMessaging::Start (pp=<value optimized out>) at /afs/cern.ch/work/a/apeters/eos-master/eos/mq/XrdMqMessaging.cc:35
#21 0x000000326f21fc2f in XrdSysThread_Xeq (myargs=<value optimized out>) at /usr/src/debug/xrootd/xrootd/src/XrdSys/XrdSysPthread.cc:86
#22 0x0000003da6a0673d in start_thread () from /lib64/libpthread.so.0
#23 0x0000003da62d44bd in clone () from /lib64/libc.so.6

xrdcp: -DI option segfaults

(Presumably similar/same as https://savannah.cern.ch/bugs/?100772 ?)

[root@lxbst2320 tmp]# gdb xrdcp
GNU gdb (GDB) Red Hat Enterprise Linux (7.0.1-45.el5)
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
...
Reading symbols from /usr/bin/xrdcp...Reading symbols from /usr/lib/debug/usr/bin/xrdcp.debug...done.
done.
(gdb) run -d 1 -v -f -DIReadCacheSize 0 -DIConnectTimeout 30 -DITransactionTimeout 60 -DIRequestTimeout 60 -DIRedirCntTimeout 60   /etc/group root://128.142.188.27//eos/ppsscratch/test/slstest-eospps/foo
Starting program: /usr/bin/xrdcp -d 1 -v -f -DIReadCacheSize 0 -DIConnectTimeout 30 -DITransactionTimeout 60 -DIRequestTimeout 60 -DIRedirCntTimeout 60   /etc/group root://128.142.188.27//eos/ppsscratch/test/slstest-eospps/foo
warning: no loadable sections found in added symbol-file system-supplied DSO at 0x2aaaaaaab000
[Thread debugging using libthread_db enabled]

Program received signal SIGSEGV, Segmentation fault.
0x000000352b478d70 in strlen () from /lib64/libc.so.6
(gdb) bt
#0  0x000000352b478d70 in strlen () from /lib64/libc.so.6
#1  0x00002aaaaad54899 in XrdOucHashVal (KeyVal=0x1d861 )
    at /usr/src/debug/xrootd/xrootd/src/XrdOuc/XrdOucHashVal.cc:37
#2  0x000000000040cf1c in XrdOucHash::Add (this=0x6194e0, KeyVal=0x1d861 , 
    KeyData=0x61a7b0 "0", LifeTime=7, opt=18) at /usr/src/debug/xrootd/xrootd/src/XrdOuc/XrdOucHash.icc:64
#3  0x00002aaaaad53858 in Rep (this=0x6194e0, varname=0x1d861 , 
    value=) at /usr/src/debug/xrootd/xrootd/src/XrdOuc/XrdOucHash.hh:169
#4  XrdOucEnv::PutInt (this=0x6194e0, varname=0x1d861 , value=)
    at /usr/src/debug/xrootd/xrootd/src/XrdOuc/XrdOucEnv.cc:185
#5  0x000000000040bebb in PutInt (argc=, argv=)
    at /usr/src/debug/xrootd/xrootd/src/XrdClient/XrdClientEnv.hh:108
#6  main (argc=, argv=)
    at /usr/src/debug/xrootd/xrootd/src/XrdApps/XrdCpy.cc:1509
(gdb) quit
A debugging session is active.

    Inferior 1 [process 23604] will be killed.

Quit anyway? (y or n) y
[root@lxbst2320 tmp]# rpm -q xrootd-client
xrootd-client-3.3.2-1.slc5

"xrdcp -d 1" prints "XrdClient counters" only to STDOUT, not to other filedescriptors?

Apparently the "XrdClient counters:" cannot be redirected to file - "xrdcp" does not emit them if STDOUT is redirected. Which is odd, since the preceding "Low level caching info:" is printed. Suggest to allow redirecting, these might have useful info and the overall amount of data compared to e.g. STDERR is negligible.

$ xrdcp -d 1 -f root://eospps//eos/testfile /dev/null 2>/dev/null

Low level caching info:
StallsRate=1
StallsCount=1
ReadsCounter=1
BytesUsefulness=0
BytesSubmitted=2097152 BytesHit=0

XrdClient counters:
ReadBytes: 1048576
WrittenBytes: 0
WriteRequests: 0
ReadRequests: 1
ReadMisses: 1
ReadHits: 0
ReadMissRate: 1.000000
ReadVRequests: 0
ReadVSubRequests: 0
ReadVSubChunks: 0
ReadVBytes: 0
ReadVAsyncRequests: 0
ReadVAsyncSubRequests: 0
ReadVAsyncSubChunks: 0
ReadVAsyncBytes: 0
ReadAsyncRequests: 0
ReadAsyncBytes: 0

$ xrdcp -d 1 -f root://eospps//eos/testfile /dev/null 2>/dev/null >/tmp/sfdhjfd; cat /tmp/sfdhjfd

Low level caching info:
StallsRate=1
StallsCount=1
ReadsCounter=1
BytesUsefulness=0
BytesSubmitted=2097152 BytesHit=0

$ rpm -qf which xrdcp
xrootd-client-3.3.3-1.slc6.x86_64

SSS auth fails with "IP address mismatch." error message on master

It looks like the two IP addresses it compares are formated differently:

sec_PM: Using sss protocol, args='0.13:/etc/eos.keytab'
sec_sss: pcitdss1400.cern.ch [::137.138.33.80]:51183 must match pcitdss1400.cern.ch [::ffff:137.138.33.80]:51183
sec_sss: Authenticate: IP address mismatch.

[XrdCl] Cannot pass flags with an asynchronous directory listing

Hi,

The DirListFlags::Flags parameter is missing from the asynchronous version of XrdCl::FileSystem::DirList.

This means that it isn't possible to retrieve stat information asynchronously with a directory listing. This causes a test case to fail in pyxrootd.

Thanks,
Justin

md5 checksum issues with xrootd-client-3.3.3-1 (change of beaviour wrt xrootd-client-3.2.2-1)

Hi,

Doing some tests for ALICE we spotted a change of behaviour in xrootd-client-3.3.3-1 with respect to xrootd-client-3.2.2.

Seems the md5 checksum on 3.2.2 was done at diskserver level whereas the md5 checksum on 3.3.3 is done at server level which doesn't know anything about it.

Would it be possible to be able to do the check at dikserver level after the transfer on xrootd-client-3.3.3 ?

Thanks.
Cheers,
Xavi.

xrootd-3.3.3 (eospps)

/usr/bin/xrdcp -d 3 -md5 -DIReadCacheSize 0 -DIMaxRedirectCount 2 -ODmode=644 /etc/group xroot://castorpublic.cern.ch//castor/cern.ch/user/x/xavierc3/testalice_testxrdcp14.dat
[...]
130910 13:25:32 5811 Xrd: DoAuthentication: server reply: status: 0 dlen: 0
130910 13:25:32 5811 Xrd: DoLogin: No prev session info for 128.142.184.247:1094.
130910 13:25:32 5811 Xrd: Connect: Access to server granted.
130910 13:25:32 5811 Xrd: Connect: Connected.
130910 13:25:32 5811 Xrd: SendGenCommand: Sending command GetChecksum

================= DUMPING CLIENT REQUEST HEADER =================
ClientHeader.streamid = 0x01 0x00
ClientHeader.requestid = kXR_query (3001)
ClientHeader.header.dlen = 66
=================== END CLIENT HEADER DUMPING ===================

130910 13:25:32 5811 Xrd: WriteRaw: Writing 24 bytes to physical connection
130910 13:25:32 5811 Xrd: WriteRaw: Writing to substreamid 0
130910 13:25:32 5817 Xrd: XrdClientMessage::ReadRaw: Reading header (8 bytes).
130910 13:25:32 5817 Xrd: ReadRaw: Reading from c2publicsrv201.cern.ch:1094
130910 13:25:32 5811 Xrd: WriteRaw: Writing 66 bytes to physical connection
130910 13:25:32 5811 Xrd: WriteRaw: Writing to substreamid 0
130910 13:25:32 5811 Xrd: ReadPartialAnswer: Reading a XrdClientMessage from the server [c2publicsrv201.cern.ch:1094]...
130910 13:25:32 5817 Xrd: XrdClientMessage::ReadRaw: sid: 1, IsAttn: 0, substreamid: 0
130910 13:25:32 5817 Xrd: XrdClientMessage::ReadRaw: Reading data (34 bytes) from substream 0
130910 13:25:32 5817 Xrd: ReadRaw: Reading from c2publicsrv201.cern.ch:1094
130910 13:25:32 5817 Xrd: BuildMessage: posting id 1
130910 13:25:32 5817 Xrd: XrdClientMessage::ReadRaw: Reading header (8 bytes).
130910 13:25:32 5817 Xrd: ReadRaw: Reading from c2publicsrv201.cern.ch:1094

======== DUMPING SERVER RESPONSE HEADER ========
ServerHeader.streamid = 0x01 0x00
ServerHeader.status = kXR_error (4003)
ServerHeader.dlen = 34
========== END DUMPING SERVER HEADER ===========

130910 13:25:32 5811 Xrd: ReadPartialAnswer: Server [c2publicsrv201.cern.ch:1094] answered kXR_error
130910 13:25:32 5811 Xrd: CheckErrorStatus: Server [castorpublic.cern.ch] declared: query chksum is not supported(error code: 3013)
xrdcp: Unable to obtain checksum for 'xroot://castorpublic.cern.ch//castor/cern.ch/user/x/xavierc3/testalice_testxrdcp20.dat'.
xrdcp: query chksum is not supported
130910 13:25:32 5811 Xrd: Disconnect: LogConnID: 2 destroyed
xrdcp: Operation not supported calculating md5 checksum for xroot://castorpublic.cern.ch//castor/cern.ch/user/x/xavierc3/testalice_testxrdcp20.dat

xrootd 3.2.2:

13:37:58:xavierc3@lxadm12:~$ /usr/bin/xrdcp -d 3 -md5 -DIReadCacheSize 0 -DIMaxRedirectCount 2 -ODmode=644 /etc/group xroot://castorpublic.cern.ch//castor/cern.ch/user/x/xavierc3/testalice_testxrdcp25.dat
[...]
130910 13:30:00 5677 Xrd: WriteRaw: Writing 24 bytes to physical connection
130910 13:30:00 5677 Xrd: WriteRaw: Writing to substreamid 0
130910 13:30:00 5677 Xrd: WriteRaw: Writing 717 bytes to physical connection
130910 13:30:00 5677 Xrd: WriteRaw: Writing to substreamid 0
130910 13:30:00 5677 Xrd: ReadPartialAnswer: Reading a XrdClientMessage from the server [lxfssl4004.cern.ch:1095]...
130910 13:30:00 5684 Xrd: XrdClientMessage::ReadRaw: sid: 1, IsAttn: 0, substreamid: 0
130910 13:30:00 5684 Xrd: BuildMessage: posting id 1
130910 13:30:00 5684 Xrd: XrdClientMessage::ReadRaw: Reading header (8 bytes).
130910 13:30:00 5684 Xrd: ReadRaw: Reading from lxfssl4004.cern.ch:1095

======== DUMPING SERVER RESPONSE HEADER ========
ServerHeader.streamid = 0x01 0x00
ServerHeader.status = kXR_ok (0)
ServerHeader.dlen = 0
========== END DUMPING SERVER HEADER ===========

md5: 6cf9b64ffd984214e23375118b6da48d /etc/group 717
130910 13:30:00 5677 Xrd: SendGenCommand: Sending command Close

Also worth to mention that en gets segmentation fault after the file has been correctly checksumed+stored (on 3.2.2-1):

[...]
130910 13:30:00 5684 Xrd: ReadRaw: Reading from lxfssl4004.cern.ch:1095
130910 13:30:00 5677 Xrd: Disconnect: LogConnID: 1 destroyed
XrdClient counters:
ReadBytes: 0
WrittenBytes: 717
WriteRequests: 1
ReadRequests: 0
ReadMisses: 0
ReadHits: 0
ReadMissRate: 0.000000
ReadVRequests: 0
ReadVSubRequests: 0
ReadVSubChunks: 0
ReadVBytes: 0
ReadVAsyncRequests: 0
ReadVAsyncSubRequests: 0
ReadVAsyncSubChunks: 0
ReadVAsyncBytes: 0
ReadAsyncRequests: 0
ReadAsyncBytes: 0

Segmentation fault

Used versions:
LXADM:
13:37:54:xavierc3@lxadm12:~$ rpm -qa| grep xrootd-client
1:xrootd-client-3.2.2-1.slc5.x86_64

EOSPPS:
13:25:32:xavierc3@lxbst2320:~$ rpm -qa|grep xrootd-client
1:xrootd-client-3.3.3-1.slc5.x86_64

which version of globus gridftp server supported by xrootd-dsi library

which version of globus gridftp server supported by xrootd-dsi library?

Server stuck with "XrdAccept: Unable to allocate new link ... ; cannot allocate memory"

From EOS bugtracker:

Date: 2013-08-08 21:08 By: Jan Iven

Downtime (neither xrootd nor SRM work), starts roughly with

130808 18:03:16 26269 XrdLink: attempt to reuse active link
130808 18:03:16 26269 XrdAccept: Unable to allocate new link for
lxplus0320.cern.ch; cannot allocate memory

These two messages become increasingly common, and start to include machines
used by the service (e.g. the gridftp doors), unless nearly nothing else is
logged. Suspect that "26269" is the main thread that accepts connections.

Must be something thread-local, machine has more than enough memory, is not
(and was not) swapping. No OOM messages either.

[root@lxbrf39c02 ~]# ps axvw | grep mgm
26269 ?        Sl   36190:13    0   177 52738946 37919324 14.3
/usr//bin/xrootd -n mgm -c /etc/xrd.cf.mgm -m -l /var/log/eos/xrdlog.mgm -b
-Rdaemon
[root@lxbrf39c02 ~]# free
             total       used       free     shared    buffers     cached
Mem:     264254700  224848388   39406312          0    1599512  178560424
-/+ buffers/cache:   44688452  219566248

"fixed" by MGM restart

eos-server-0.2.38-1
xrootd-server-3.2.8-1.slc5

Date: 2013-08-09 10:58 By: Lukasz Janyst

Surprisingly enough this has nothing to do with memory allocation.

XrdLink::Alloc() would return the same error code for the case where the link
is already allocated and in use and for the case where it could not have been
allocated because of lack of memory.

Then, the code calling XrdLink::Alloc has no way of distinguishing between
the two cases and assumes a memory problem - thus the error message you see.

This should be reported in xrootd bug tracker.

extra opage information on end of xrdcp (?oss.cgroup=XXXXX) cause copy to fail

example of failed transfer -

[apf@hpcwork02 ~]$ /usr/bin/xrdcp -d 1 pilotlog.txt root://atlasfs02.hep.anl.gov:1094//grid/atlas/dq2/ATLASUSERDISK/panda/test/pilotlog.txt?oss.cgroup=ATLASUSERDISK
131105 14:18:49 19132 Xrd: main: (C) 2004-2011 by the XRootD collaboration. Version: v3.3.4
131105 14:18:49 19132 Xrd: Create: (C) 2004-2010 by the Xrootd group. XrdClient $Revision$ - Xrootd version: v3.3.4
131105 14:18:49 19132 Xrd: ShowUrls: The converted URLs count is 1
131105 14:18:49 19132 Xrd: ShowUrls: URL n.1: root://atlasfs02.hep.anl.gov:1094//grid/atlas/dq2/ATLASUSERDISK/panda/test/pilotlog.txt?oss.cgroup=ATLASUSERDISK&oss.asize=50075.
131105 14:18:49 19132 Xrd: ShowUrls: The converted URLs count is 1
131105 14:18:49 19132 Xrd: ShowUrls: URL n.1: root://atlasfs02.hep.anl.gov:1094//grid/atlas/dq2/ATLASUSERDISK/panda/test/pilotlog.txt?oss.cgroup=ATLASUSERDISK&oss.asize=50075.
sec_Client: protocol request for host atlasfs02.hep.anl.gov token='&P=unix'
sec_PM: Loading unix protocol object from libXrdSecunix.so
sec_PM: Using unix protocol, args=''
131105 14:18:49 19132 Xrd: Open: Access to server granted.
131105 14:18:49 19132 Xrd: Open: Opening the remote file /grid/atlas/dq2/ATLASUSERDISK/panda/test/pilotlog.txt?oss.cgroup=ATLASUSERDISK&oss.asize=50075
131105 14:18:49 19132 Xrd: Open: File open in progress.
131105 14:18:49 19135 Xrd: CheckErrorStatus: Server [atlasfs02.hep.anl.gov:1094] declared: Unable to create /grid/atlas/dq2/ATLASUSERDISK/panda/test/pilotlog.txt; no such file or directory(error code: 3011)
xrdcp: Copy to atlasfs02.hep.anl.gov failed on open!
xrdcp: Unable to create /grid/atlas/dq2/ATLASUSERDISK/panda/test/pilotlog.txt; no such file or directory

Successful transfer without opaque information -

[apf@hpcwork02 ~]$ /usr/bin/xrdcp -d 1 pilotlog.txt root://atlasfs02.hep.anl.gov:1094//grid/atlas/dq2/ATLASUSERDISK/panda/test/pilotlog.txt
131105 14:19:19 20504 Xrd: main: (C) 2004-2011 by the XRootD collaboration. Version: v3.3.4
131105 14:19:19 20504 Xrd: Create: (C) 2004-2010 by the Xrootd group. XrdClient $Revision$ - Xrootd version: v3.3.4
131105 14:19:19 20504 Xrd: ShowUrls: The converted URLs count is 1
131105 14:19:19 20504 Xrd: ShowUrls: URL n.1: root://atlasfs02.hep.anl.gov:1094//grid/atlas/dq2/ATLASUSERDISK/panda/test/pilotlog.txt?oss.asize=50075.
131105 14:19:19 20504 Xrd: ShowUrls: The converted URLs count is 1
131105 14:19:19 20504 Xrd: ShowUrls: URL n.1: root://atlasfs02.hep.anl.gov:1094//grid/atlas/dq2/ATLASUSERDISK/panda/test/pilotlog.txt?oss.asize=50075.
sec_Client: protocol request for host atlasfs02.hep.anl.gov token='&P=unix'
sec_PM: Loading unix protocol object from libXrdSecunix.so
sec_PM: Using unix protocol, args=''
131105 14:19:19 20504 Xrd: Open: Access to server granted.
131105 14:19:19 20504 Xrd: Open: Opening the remote file /grid/atlas/dq2/ATLASUSERDISK/panda/test/pilotlog.txt?oss.asize=50075
131105 14:19:19 20504 Xrd: Open: File open in progress.
131105 14:19:19 20504 Xrd: main: pilotlog.txt --> root://atlasfs02.hep.anl.gov:1094//grid/atlas/dq2/ATLASUSERDISK/panda/test/pilotlog.txt
[xrootd] Total 0.05 MB |====================| 100.00 % [inf MB/s]
Low level caching info:
StallsRate=0
StallsCount=0
ReadsCounter=0
BytesUsefulness=0
BytesSubmitted=0 BytesHit=0

XrdClient counters:
ReadBytes: 0
WrittenBytes: 50075
WriteRequests: 1
ReadRequests: 0
ReadMisses: 0
ReadHits: 0
ReadMissRate: 0.000000
ReadVRequests: 0
ReadVSubRequests: 0
ReadVSubChunks: 0
ReadVBytes: 0
ReadVAsyncRequests: 0
ReadVAsyncSubRequests: 0
ReadVAsyncSubChunks: 0
ReadVAsyncBytes: 0
ReadAsyncRequests: 0
ReadAsyncBytes: 0

xrdfs locate -r issue

We have 23 FAX endpoints that exhibit this problem:
I try to locate a file that we know exist at each of the sites by doing "xrdfs server.name locate -r theFile". These endpoints will wait some time (~1 min) and fail with message "too many redirections"
At the same time simple xrdcp of the same file from each of the sites work.

two examples:
Here both commands work:
xrdcp -f -np -d 1 root://grid-cert-03.roma1.infn.it:1094//atlas/dq2/user/HironoriIto/user.HironoriIto.xrootd.infn-roma1/user.HironoriIto.xrootd.infn-roma1-1M - > /dev/null

xrdfs grid-cert-03.roma1.infn.it:1094 locate -r //atlas/dq2/user/HironoriIto/user.HironoriIto.xrootd.infn-roma1/user.HironoriIto.xrootd.infn-roma1
[::141.108.38.30]:1094 Server Read

Here second command does not find the file and redirects upstream:
xrdcp -f -np -d 1 root://xrootd-atlas.cr.cnaf.infn.it:1094//atlas/dq2/user/HironoriIto/user.HironoriIto.xrootd.infn-t1/user.HironoriIto.xrootd.infn-t1-1M - > /dev/null

xrdfs xrootd-atlas.cr.cnaf.infn.it:1094 locate -r //atlas/dq2/user/HironoriIto/user.HironoriIto.xrootd.infn-t1/user.HironoriIto.xrootd.infn-t1
[FATAL] Redirect limit has been reached

Full list of sites may be found here: http://dashb-atlas-ssb.cern.ch/dashboard/request.py/siteview?view=FAX%20endpoints#currentView=FAX%2520endpoints&highlight=false

Ilija

SSS segmentation fault

I am using the latest build from the master branch:
xrootd-server-devel-20131030.c012b93-1.slc6.x86_64

When starting EOS the manager node crashes with the following output:

131104 16:55:34 time=1383580534.469811 func=open level=INFO logid=8a41cb52-4569-11e3-849b-b8ac6f295cec unit=[email protected]:1094 tid=00007f1782e5d700 source=XrdMgmOfsFile:194 tident=root.12935:7@
pcitdss1400 sec= sss uid=2 gid=2 name=daemon geo="" op=read path=/proc/admin/ info=mgm.cmd=fs&mgm.dumpmd.option=m&mgm.dumpmd.storetime=1&mgm.format=fuse&mgm.fsid=1&mgm.subcmd=dumpmd
131104 16:55:34 12562 XrootdXeq: root.12935:7@pcitdss1400 disc 0:00:00
*** glibc detected *** /usr//bin/xrootd: double free or corruption (fasttop): 0x00007f174c002610 ***
======= Backtrace: =========
/lib64/libc.so.6[0x331f076126]
/usr/lib64/libXrdSecsss.so(_ZN17XrdSecProtocolsss6DeleteEv+0x25)[0x7f17821ddfb5]
/usr//bin/xrootd(_ZN17XrdXrootdProtocol7CleanupEv+0x142)[0x41d122]
/usr//bin/xrootd(_ZN17XrdXrootdProtocol7RecycleEP7XrdLinkiPKc+0xc7)[0x41e3d7]
/usr/lib64/libXrdUtils.so.1(_ZN7XrdLink5CloseEi+0x110)[0x7f178382bcd0]
/usr/lib64/libXrdUtils.so.1(_ZN12XrdScheduler3RunEv+0xd5)[0x7f178382ff05]
/usr/lib64/libXrdUtils.so.1(_Z15XrdStartWorkingPv+0x9)[0x7f17838300f9]
/usr/lib64/libXrdUtils.so.1(XrdSysThread_Xeq+0x3f)[0x7f17837fa17f]
/lib64/libpthread.so.0[0x331fc07851]
/lib64/libc.so.6(clone+0x6d)[0x331f0e894d]
======= Memory map: ========
00400000-00437000 r-xp 00000000 fd:00 397970 /usr/bin/xrootd
00636000-00638000 rw-p 00036000 fd:00 397970 /usr/bin/xrootd
00638000-00639000 rw-p 00000000 00:00 0

......

And some info about the thread that seg fault:
Thread 37 (Thread 0x7f1782e5d700 (LWP 12562)):
#0 0x000000331f0ac7ed in waitpid () from /lib64/libc.so.6
#1 0x000000331f03e8c9 in do_system () from /lib64/libc.so.6
#2 0x000000331f03ec00 in system () from /lib64/libc.so.6
#3 0x00007f1781a582a8 in GdbTrace (sig=6) at /home/esindril/Programs/eos/mgm/../common/StackTrace.hh:65
#4 xrdmgmofs_stacktrace (sig=6) at /home/esindril/Programs/eos/mgm/XrdMgmOfs.cc:116
#5
#6 0x000000331f0328e5 in raise () from /lib64/libc.so.6
#7 0x000000331f0340c5 in abort () from /lib64/libc.so.6
#8 0x000000331f0707f7 in libc_message () from /lib64/libc.so.6
#9 0x000000331f076126 in malloc_printerr () from /lib64/libc.so.6
#10 0x00007f17821ddfb5 in XrdSecProtocolsss::Delete() () from /usr/lib64/libXrdSecsss.so
#11 0x000000000041d122 in XrdXrootdProtocol::Cleanup() ()
#12 0x000000000041e3d7 in XrdXrootdProtocol::Recycle(XrdLink, int, char const) ()
#13 0x00007f178382bcd0 in XrdLink::Close(int) () from /usr/lib64/libXrdUtils.so.1
#14 0x00007f178382ff05 in XrdScheduler::Run() () from /usr/lib64/libXrdUtils.so.1
#15 0x00007f17838300f9 in XrdStartWorking(void*) () from /usr/lib64/libXrdUtils.so.1
#16 0x00007f17837fa17f in XrdSysThread_Xeq () from /usr/lib64/libXrdUtils.so.1
#17 0x000000331fc07851 in start_thread () from /lib64/libpthread.so.0
#18 0x000000331f0e894d in clone () from /lib64/libc.so.6

Thanks,
Elvin

Broken xrootd repository - cause update to fail

Hello We are seeing this behaviour likely caused by a malformed yum repository.

We have installed xrootd (SL6.4 x86_64) from xrootd.org

[root@atl004 ~]# cat /etc/yum.repos.d/xrootd-stable.repo
[xrootd-stable]
name=XRootD Stable repo
baseurl=http://xrootd.org/binaries/stable/slc/6/$basearch/
enabled=1
gpgcheck=0

Note -- The epel repository is not installed on the machine.

Here is what is installed from xrootd.org -

[root@atl004 ~]# yum list installed xrootd*
Loaded plugins: security
cernvm | 2.3 kB 00:00
physics | 951 B 00:00
sl | 3.7 kB 00:00
sl-security | 3.0 kB 00:00
sl6x | 3.7 kB 00:00
sl6x-security | 3.0 kB 00:00
xrootd-stable | 951 B 00:00
Installed Packages
xrootd.x86_64 1:3.3.3-1.slc6 @xrootd-stable
xrootd-client.x86_64 1:3.3.3-1.slc6 @xrootd-stable
xrootd-client-devel.x86_64 1:3.3.3-1.slc6 @xrootd-stable
xrootd-client-libs.x86_64 1:3.3.3-1.slc6 @xrootd-stable
xrootd-debuginfo.x86_64 1:3.3.3-1.slc6 @xrootd-stable
xrootd-devel.x86_64 1:3.3.3-1.slc6 @xrootd-stable
xrootd-doc.noarch 1:3.3.3-1.slc6 @xrootd-stable
xrootd-fuse.x86_64 1:3.3.3-1.slc6 @xrootd-stable
xrootd-libs.x86_64 1:3.3.3-1.slc6 @xrootd-stable
xrootd-server-devel.x86_64 1:3.3.3-1.slc6 @xrootd-stable
xrootd-server-libs.x86_64 1:3.3.3-1.slc6 @xrootd-stable

Yet when we issue the yum update command for xrootd we get these errors:

[root@atl004 ~]# yum update xrootd*
Loaded plugins: security
Setting up Update Process
Resolving Dependencies
--> Running transaction check
---> Package xrootd.x86_64 1:3.3.3-1.slc6 will be obsoleted
---> Package xrootd-server.x86_64 1:3.3.1-1.slc6.xu will be obsoleting
--> Processing Dependency: xrootd-client = 1:3.3.1-1.slc6.xu for package: 1:xrootd-server-3.3.1-1.slc6.xu.x86_64
--> Processing Dependency: xrootd-libs = 1:3.3.1-1.slc6.xu for package: 1:xrootd-server-3.3.1-1.slc6.xu.x86_64
--> Finished Dependency Resolution
Error: Package: 1:xrootd-server-3.3.1-1.slc6.xu.x86_64 (xrootd-stable)
Requires: xrootd-client = 1:3.3.1-1.slc6.xu
Installed: 1:xrootd-client-3.3.3-1.slc6.x86_64 (@xrootd-stable)
xrootd-client = 1:3.3.3-1.slc6
Available: 1:xrootd-client-3.2.0-1.slc6.xu.x86_64 (xrootd-stable)
xrootd-client = 1:3.2.0-1.slc6.xu
Available: 1:xrootd-client-3.2.1-1.slc6.xu.x86_64 (xrootd-stable)
xrootd-client = 1:3.2.1-1.slc6.xu
Available: 1:xrootd-client-3.2.2-1.slc6.xu.x86_64 (xrootd-stable)
xrootd-client = 1:3.2.2-1.slc6.xu
Available: 1:xrootd-client-3.2.3-1.slc6.xu.x86_64 (xrootd-stable)
xrootd-client = 1:3.2.3-1.slc6.xu
Available: 1:xrootd-client-3.2.4-1.slc6.xu.x86_64 (xrootd-stable)
xrootd-client = 1:3.2.4-1.slc6.xu
Available: 1:xrootd-client-3.2.5-1.slc6.xu.x86_64 (xrootd-stable)
xrootd-client = 1:3.2.5-1.slc6.xu
Available: 1:xrootd-client-3.2.6-1.slc6.xu.x86_64 (xrootd-stable)
xrootd-client = 1:3.2.6-1.slc6.xu
Available: 1:xrootd-client-3.2.7-1.slc6.xu.x86_64 (xrootd-stable)
xrootd-client = 1:3.2.7-1.slc6.xu
Available: 1:xrootd-client-3.3.0-1.slc6.xu.x86_64 (xrootd-stable)
xrootd-client = 1:3.3.0-1.slc6.xu
Available: 1:xrootd-client-3.3.1-1.slc6.xu.x86_64 (xrootd-stable)
xrootd-client = 1:3.3.1-1.slc6.xu
Error: Package: 1:xrootd-server-3.3.1-1.slc6.xu.x86_64 (xrootd-stable)
Requires: xrootd-libs = 1:3.3.1-1.slc6.xu
Installed: 1:xrootd-libs-3.3.3-1.slc6.x86_64 (@xrootd-stable)
xrootd-libs = 1:3.3.3-1.slc6
Available: 1:xrootd-libs-3.2.0-1.slc6.xu.x86_64 (xrootd-stable)
xrootd-libs = 1:3.2.0-1.slc6.xu
Available: 1:xrootd-libs-3.2.1-1.slc6.xu.x86_64 (xrootd-stable)
xrootd-libs = 1:3.2.1-1.slc6.xu
Available: 1:xrootd-libs-3.2.2-1.slc6.xu.x86_64 (xrootd-stable)
xrootd-libs = 1:3.2.2-1.slc6.xu
Available: 1:xrootd-libs-3.2.3-1.slc6.xu.x86_64 (xrootd-stable)
xrootd-libs = 1:3.2.3-1.slc6.xu
Available: 1:xrootd-libs-3.2.4-1.slc6.xu.x86_64 (xrootd-stable)
xrootd-libs = 1:3.2.4-1.slc6.xu
Available: 1:xrootd-libs-3.2.5-1.slc6.xu.x86_64 (xrootd-stable)
xrootd-libs = 1:3.2.5-1.slc6.xu
Available: 1:xrootd-libs-3.2.6-1.slc6.xu.x86_64 (xrootd-stable)
xrootd-libs = 1:3.2.6-1.slc6.xu
Available: 1:xrootd-libs-3.2.7-1.slc6.xu.x86_64 (xrootd-stable)
xrootd-libs = 1:3.2.7-1.slc6.xu
Available: 1:xrootd-libs-3.3.0-1.slc6.xu.x86_64 (xrootd-stable)
xrootd-libs = 1:3.3.0-1.slc6.xu
Available: 1:xrootd-libs-3.3.1-1.slc6.xu.x86_64 (xrootd-stable)
xrootd-libs = 1:3.3.1-1.slc6.xu
You could try using --skip-broken to work around the problem
You could try running: rpm -Va --nofiles --nodigest

Some how the xrootd-server package is required as part of the dependencies yet
it is an older version and we did not install it.

Any idea what might be causing these errors?