Xrdcp writes file to redirector but crashes

ROOT
1

Here are the last few lines of xrdcp -d3 output file. This started after all systems were updated using ManageTeir3SW.sh. Root is 5.26, os is SL55-64bit. Any ideas on trouble shooting would be helpful. Full debug output and conf files are available.

key=‘stephen_gray@dellatlas:1094’, LogCnt=1 Valid
101203 12:58:49 4392 Xrd: DumpPhyConn: Phyconn entry, key=‘stephen_gray@dellatlas:1094’, LogCnt=1 Valid
101203 12:58:49 4392 Xrd: ClientSock::RecvRaw: Request timed out 300seconds reading 8 bytes from server dellatlas:1094
101203 12:58:49 4392 Xrd: XrdClientMessage::ReadRaw: sid: 0, IsAttn: 0, substreamid: 0
101203 12:58:49 4392 Xrd: BuildMessage: deleting id 0
101203 12:58:49 4392 Xrd: XrdClientMessage::ReadRaw: Reading header (8 bytes).
101203 12:58:49 4392 Xrd: ReadRaw: Reading from dellatlas:1094
101203 12:59:03 001 Xrd: ClientSock::SendRaw: Request timed out 300seconds writing 4194304 bytes to server dellatlas:1094
101203 12:59:03 001 Xrd: WriteRaw: Disconnection reported ondellatlas:1094
101203 12:59:03 001 Xrd: PhyConnection: Disconnecting socket…
101203 12:59:03 001 Xrd: WriteToServer: Error sending 4194304 bytes in the data part to server [dellatlas:1094].
101203 12:59:03 001 Xrd: SendGenCommand: Sending command Write

================= DUMPING CLIENT REQUEST HEADER =================
ClientHeader.streamid = 0x01 0x00
ClientHeader.requestid = kXR_write (3019)
ClientHeader.write.fhandle = 0x00 0x00 0x00 0x00
ClientHeader.write.offset = 0
ClientHeader.write.pathid = 0
ClientHeader.write.reserved = 0 repeated 3 times
ClientHeader.header.dlen = 4194304
=================== END CLIENT HEADER DUMPING ===================

101203 12:59:03 001 Xrd: WriteRaw: Writing 24 bytes to physical connection
101203 12:59:03 001 Xrd: WriteRaw: Socket is disconnected.
101203 12:59:03 001 Xrd: WriteToServer: Error sending 24 bytes in the header part to server [dellatlas:1094].
101203 12:59:03 001 Xrd: Cache: Cache Status --------------------------
101203 12:59:03 001 Xrd: Cache blk: 0Data block 0->4194303 (pinned)
101203 12:59:03 001 Xrd: Cache: -------------------------------------- fTotalByteCount = 0
101203 12:59:03 001 Xrd: PhyConnection: Disconnecting socket…
101203 12:59:03 001 Xrd: DumpPhyConn: Phyconn entry, key=‘stephen_gray@dellatlas:1094’, LogCnt=1 NotValid
101203 12:59:03 001 Xrd: PhyConnection: Disconnecting socket…
101203 12:59:03 001 Xrd: DumpPhyConn: Phyconn entry, key=‘Trashed connection’, LogCnt=1 NotValid
101203 12:59:03 001 Xrd: Disconnect: LogConnID: 0 destroyed
101203 12:59:03 001 Xrd: HandleServerError: Redir count=1
101203 12:59:03 001 Xrd: SendGenCommand: Max time limit elapsed for request kXR_write. Aborting command.
Error writing to output server.
Last server error 10000 (’’)

2

Hi,

from the log that you have pasted it looks like you have managed successfully open the file for writing but didn’t manage to write any data because the connection timed out. This may mean that the link has been physically interrupted.

Could you describe in more details what you’re trying to do? You don’t usually write files to a redirector… What is ManageTeir3SW.sh?

Lukasz

3

Trying to move files from remote system to lab and kick off a python job under root-5.26. The redirector receives the file, but generates the timeout error. After the error is generated, I cant talk to the file to kickoff the python job. The xrdcp command worked before the software update----the python job required ver 2.5.2. I had the standard python delivered wth SL55. Python would not compile or generate an rpm from src—tkinter.so not found. I was told ManageTeir3SW.sh script would fix the version misalignments. This is a script that pulls software from cern, slac, and other contributor locations. The script then generated several new versions of Gcc, root, python, etc. The script also generated scripts to update the SL55 environment variables to align libraries and executable locations.

Thanks for the response.

Stephen.

4

Sorry for the late response, I haven’t noticed your message earlier.

I have never heard of the ManageTeir3SW.sh script before and I don’t know what it does exactly so it may be the cause of your problem.

There is also a new timeout option introduced recently in the client that may be at fault. This new feature, called the transaction timeout, causes the client to abort any on-going operation if it takes more than an arbitrary amount of time - AFAIK it is 300 seconds in case of ROOT 5.26. I find it unlikely to be the problem here though, because it looks like your server rejects the first 4MB chunk of data. In any case, you can try to increase this timeout value and retry.

The incantation to do that is: