Hi Pete,
> xrootd itself doesn't create any such file.
Actually, xrootd does create such a file. I don't mind turning that off by
default. Next release I suppose.
> This presumably permits one to run only one olbd on any given machine
> at a time, no? That would seem to disallow the separate "test system"
> that we have discussed in the past from running on the same set of hardware.
No, not really since you can specify the name/location of the pidfile.
> What exactly uses this file to notify the olbd? The xrootd on the redirector
> finds its olbd via the "odc.manager" directive, correct?
External scripts use it to a) verify that the right olbd is running, and
b) figure out what the path prefix is (the olbd exports that to the
pidfile). Both are necessary for file status change notification.
> Ah, what happens on the data servers? If I have understood correctly the
> default is that the xrootd there does _not_ connect to its olbd on its
> data server. If the "-t" option is used with xrootd (config directive
> "ofs.redirect target") it _will_ connect with the olbd and if the olbd in
> addition has "-w" ("olb.wait") enabled it won't actually agree to have
> anything redirected at it unless an xrootd is in fact connected. Since
> "ofs.redirect target" doesn't in fact take a port argument, how does the
> xrootd on the data server find the olbd? Is it using the /tmp/olbd.pid file?
> Besides enabling this mechanism, what else does the data server xrootd
> connecting with its olbd allow?
Good deduction sherlock! However, we needed security here so communication
takes place via a named unix socket whose name is configurable. So, no
conflict.
Andy
