 |
 |
Hi Gregory, I see I see... Could you send me the complete log file. That is from the point that the server was actually started so that I can see the full set of options really in effect. Could you also indicate the existence, mode bits and ownership associated with "/home/xrootd/disk/kanga/EventStore" on the machine that where the xrootd runs. Thanks. Andy ----- Original Message ----- From: "Gregory Schott" <[log in to unmask]> To: "abh" <[log in to unmask]> Cc: "Peter Elmer" <[log in to unmask]>; <[log in to unmask]> Sent: Wednesday, March 30, 2005 4:02 PM Subject: Re: xrootd meeting - Tuesday 29 March, 2005 > Hello Andy, > > About my writing problem... > > I got confused and probably got you confused too but I don't want (and > need) this machine to be managed by the redirector. I had however > forgotten to comment the odc.manager option. > > == > > My config file is then the following (I believe it is a config file > problem): > > # dataserver.cf > # > oss.alloc * * 80 > oss.fdlimit * max > oss.localroot /home/xrootd/disk/kanga/EventStore/ > #oss.path /home/xrootd/disk/kanga/EventStore/ writable > > xrd.protocol xrootd * > > xrootd.export /prod > xrootd.export /store > xrootd.fslib /home/xrootd/software/current/lib/libXrdOfs.so > > odc.trace redirect > olb.trace all > oss.trace all > xrd.trace all > xrootd.trace all > > == > > The error message I get with xrdcp is: > > Error accessing path/file for root://f01-001-124:1094//prod/dummy.root > > PS: I can actually read the file if I xrdcp the other way around so the > path is accessible for read. According to the documentation the default is > write allowed (except if I use oss.readonly). The unix directory rights > also allow xrootd to write there. > > == > > And in the (verbose) log file is: > > 050331 01:51:45 15028 Exporting /store > 050331 01:51:45 15028 Exporting /prod > 050331 01:51:45 15028 XRootd protocol version 2.2.0 build 20040907-0403 > successfully loaded. > 050331 01:51:45 15028 xrd@f01-001-124:1094 initialization completed. > 050331 01:51:45 15028 XrdMain: thread 10251 assigned to user handler > 050331 01:52:14 15042 XrdNet: Accepted tcp connection from > l01-001-122.gridka.de > 050331 01:52:14 15042 ?:[log in to unmask] XrdUser: connection > accepted > 050331 01:52:14 15035 XrdSched: new worker; tid=11276; num=2 > 050331 01:52:14 15035 XrdSched: running [log in to unmask] inq=0 > 050331 01:52:14 15035 XrdProtocol: matched protocol xrootd > 050331 01:52:14 15035 ?:[log in to unmask] XrdPoll: FD 13 attached > to poller 0; num=1 > 050331 01:52:14 15035 ?:[log in to unmask] XrootdProtocol: 0000 > req=3007 dlen=0 > 050331 01:52:14 15035 xrootd.12395:[log in to unmask] > XrootdResponse: 0000 sending OK > 050331 01:52:14 15035 XrootdXeq: User logged in as > xrootd.12395:[log in to unmask] > 050331 01:52:14 15035 xrootd.12395:[log in to unmask] > XrootdProtocol: 0000 req=3010 dlen=16 > 050331 01:52:14 15035 ofs_open: xrootd.12395:[log in to unmask] > Unable to create /prod/dummy.root; No such file or directory > 050331 01:52:14 15035 xrootd.12395:[log in to unmask] > XrootdResponse: 0000 sending err 3011: Unable to create /prod/dummy.root; > No such file or directory > 050331 01:52:14 15035 xrootd.12395:[log in to unmask] XrdPoll: > sending poller 0 detach for link 13 > 050331 01:52:14 15036 XrdPoll: Poller 0 detached fd 13 entry 1 now at 1 > 050331 01:52:14 15035 xrootd.12395:[log in to unmask] XrdPoll: FD 13 > detached from poller 0; num=0 > 050331 01:52:14 15035 XrdLink: xrootd.12395:[log in to unmask] > disconnected after 0:00:00 > > > -- Gregory > > > > On Tue, 29 Mar 2005, abh wrote: > >>> 050329 19:08:51 6914 odc_Open: Unable to connect socket >>> /tmp/.olb/olbd.admin; connection refused >> Is teh log truncated or did this connection succeed? >> >> >>> bash-2.05a$ cat config/dataserver.cf >>> odc.manager babar2 3121 >> Probably doesn't make a difference but one should expand this out >> completely with the domain name. >> >>> #olb.subscribe babar2 3121 >> Same thing about expansion. However, why is this commented out? With a >> sunscribe entry, no data server will particpate in the setup. So, this >> system should not work (in fact it should complain and the olbd should >> exit on the adat servers). >