 |
 |
Hi Gregory, I should have a fix for the DNS problem by this weekend. I'm not quite sure how we'll release that due to release timeframes. So, stay tuned! Andy ----- Original Message ----- From: "Gregory Schott" <[log in to unmask]> To: "abh" <[log in to unmask]> Cc: "Wilko Kroeger" <[log in to unmask]>; "Peter Elmer" <[log in to unmask]>; <[log in to unmask]> Sent: Wednesday, March 30, 2005 10:16 PM Subject: Re: xrootd meeting - Tuesday 29 March, 2005 > Hello Andy and Wilko, > > Yes I realise it is due to the software version I am running on this > dataserver. The september one did not support writting. > > I cannot use the latest online versions due to the DNS problem crashing > xrootd. > > What I could do would be to use a version from January but these are not > downloadable anymore! Why do you hide older versions? Do I have to do a > website 'mirroring' so that I can use, in the future, the software version > I need? > > Cheers, > Gregory > > > On Wed, 30 Mar 2005, abh wrote: > >> Hi Gregory & Wilko, >> >> Yes, now I recall. Sorry, I though you were running the latest version. >> The version you are running was not able to export more than one >> directory. Thanks Wilko for reminding me of that! >> >> Andy >> >> ----- Original Message ----- From: "Wilko Kroeger" >> <[log in to unmask]> >> To: "Gregory Schott" <[log in to unmask]> >> Cc: "abh" <[log in to unmask]>; "Peter Elmer" <[log in to unmask]>; >> <[log in to unmask]> >> Sent: Wednesday, March 30, 2005 5:50 PM >> Subject: Re: xrootd meeting - Tuesday 29 March, 2005 >> >> >>> >>> Hello Gregory >>> >>> Does it work to write to root://f01-001-124:1094////tmp/dummy.root ? >>> I just installed your version and I also see that I can't write to >>> xrootd >>> except /tmp. Even in this case the message, >>> Error accessing path/file for root://datadevsol01:2094////tmp/trds.test >>> is printed but the file is actually transfered. >>> >>> Could you install a newer version of xrootd? I see that you are using >>> the >>> version 20040907-0403 which is quite old. The best would be to use the >>> version 20050328-0656. >>> >>> Cheers, >>> Wilko >>> >>> >>> >>> >>> >>> On Thu, 31 Mar 2005, Gregory Schott wrote: >>> >>>> 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). >>>> >>> >> >