Hello Andrew,

>> 1) There are two network interfaced on the redirector. The issue is that
>> using the wrong one in the KanAccess file (the one that is not the same as
>> in the xrootd config files) causes to crash the xrootd (and not olbd)
>> proccess on the redirector.
>> The core file reveals:
>>> gdb /opt/xrootd/bin/xrootd core.9418
>> #0  0x0806349c in XrdNetwork::getHostName ()
> Yes, this is a known problem. The xrootd will crash if it cannot do a
> reverse translation of IP address to DNS name for it's own machine. I
> should be more graceful and issue an error message and exit. That's on the
> list of corrections.
>> 2) Strange disk size in the olb redirector log file. I'm using the sep 04
>> prod version.
>> 050216 18:49:32 9419 olb_a2i: tot dsk value -1463812096 is too small
>> 050216 18:49:32 9419 olb_Server: invalid response from
> What release are you using? This was a problem in some early releases
> dealing with the way parameters were being passed to a function and how
> the compiler treated them. It worked using Sun CC but not in g++.

As I said, it's the september 2004 production version that I'm running. I 
think I remember Jean-Yves told me that using the same release he's not 
seeing this problem at IN2P3. He's not running on linux there though.

>> 3) Probably it's a result of the computing center's instability of
>> last weekbut most of the dataservers are not registering with olbd on
> the
>> redirector. Only the dataservers that I restarted are now registering. The
>> olb logfile of the ones not registering are showing:
>> 050211 00:00:00 20383 olb_Config: (c) 2004 SLAC olbd version 20040907-0403 executing as  Server
>> 050211 14:33:02 20388 olb_Manager: Manager babar2 appears to be dead.
>> 050211 14:35:15 20388 olb_Manager: Manager h^RBh^RB appears to be dead.
>> 050211 15:03:05 1143 olb_Config: (c) 2004 SLAC olbd version 20040907-0403 initializing as Server
>> 050211 15:03:05 1143 olb_Config: Server initialization completed.
>> 050211 15:03:05 1155 olb_Start: Waiting for primary server to login.
>> 050211 15:03:06 1157 olb_Admin_Login: Primary server 1142 logged in
>> 050211 15:03:06 1143 olb_Server: Logged into babar2
>> 050211 16:14:01 1149 olb_Manager: Manager babar2 appears to be dead.
>> 050211 16:16:14 1149 olb_Manager: Manager h^RBh^RB appears to be dead.
>> 050211 16:18:27 1149 olb_Manager: Manager p^p^ appears to be dead.
>> 050211 16:20:40 1149 olb_Manager: Manager p^p^ appears to be dead.
>> 050211 16:22:54 1149 olb_Manager: Manager p^p^ appears to be dead.
>> 050211 16:25:07 1149 olb_Manager: Manager p^p^ appears to be dead.
>> Indeed, babar2 has been that day (11/02/2005) around 16:12. This message
>> kept  going on in the log file until I restarted all the dataserver's
>> processes yesterday.
> Other people have complained about this and it appears that the 20040907
> release is definitely bad. Please switch to the 200408 release we are
> using for BaBar analysis (or try the 200502 development release if you are
> adevnturous). Also, it appears that the DNS name is getting screwed up (at
> least in the messages). Please do a gcore and send me the executable and
> core file (or place it in an accessible area).

One problem of the xrootd page is that I can't find any link to that 
version and cannot list the download directory. I'm not sure I want to 
install this version, but where can I find it?

How and where should I do this gcore? (On the redirector or dataserver?)
Please, also note that since babar2 reboot I've killed and restarted all 
xrootd/olbd processes so I don't have processes in the state described 
above until next babar2 reboot.

-- Gregory

> All of this points out to a packaging problem we have. The only way we
> really test releases is to create what we call a development release. That,
> unfortunately, makes it available to everyone else -- even before we can
> certify it as being materially correct. I do know we've had some
> development releases that should have never seen the light of day, but
> unfortuantely the process lets them out. We are trying to get a new
> process in to place that will *never* cut a release unless we know that it
> will actually work on a reasonablly sized system.
> Andy

-------------- Dr. Gregory Schott --------------
  Institut fuer Experimentelle Kernphysik (IEKP)
      Universitaet Karlsruhe - Postfach 3640
            76021 Karlsruhe  (Germany)
             tel.: +49-(0)724782-3537
             fax.: +49-(0)724782-3414
            e-mail: [log in to unmask]