 |
 |
The issue here is that the xrootd@storage06 is not rendezvousing wit the cmsd@storage02 and hence the cmsd will not start talking to the redirector until that happens. The line here in he cmsd.log:
201209 12:26:29 17136 Start: Waiting for primary server to login.
On the other hand, the xrootd thinks it's connected to the cmsd as shown in the xrd.log:
201209 12:26:30 17160 cms_Finder: Connected to cmsd via /tmp/xrootd_1000/storage01/storage01/.olb/olbd.admin
When this happens it means that the path to the named pipe for the xrootd is not the same as the one the cmsd is using. The xrootd wants to use "/tmp/xrootd_1000/storage01/storage01/.olb/olbd.admin". Unfortunately, we don't display that in the cmsd log and we will correct that in a future release.
How does this happen? Usually because a) the instance names differ (i.e. the -n command line option), or b) the adminpaths differ. Since there was no all.adminpath directive in the config file, it must have been supplied by on the command line using the -a or the -A command line option. Unfortunately, we do not display the command line in the log file so I can't tell (we will coret that in a future release).
Some unrelated observations:
Placing he adminpath in "/tmp" is highly discouraged. Various control files are placed in this path and many sites (perhaps not yours) run a /tmp cleanup daemon that happily deletes old files in /tmp. If that happens to files in the adminpath the system will likely stop working. The message in the log draws attention to this:
Config warning: adminpath resides in /tmp and may be unstable!
There is an error in the config file as noted by the message:
Config warning: ignoring unknown directive 'e/aliprod/data'.
=====> oss.namelib /usr/lib64/libXrdAggregatingName2Name.so /home/aliprod/data
This is a bug (thank you for tripping over it) and will be corrected in 5.1.0.
There is no reason to scan idle links for the cmsd and, in fact, is discouraged as it causes unnecessary disconnections. The xrd.timeout directive should only apply to the xrootd. This is especially true because of the remarkably short idle timeout of 10 seconds that causes the system to scan all the links every 6 seconds. Is it necessary to have such a short timeout?
I hope starting the servers in debugging mode was for my benefit. Running servers at this debugging mode easily reduces performance by as much as 50% along with creating huge log files.
So, all I need to see is what the startup command line was for each server (xrootd and cmsd) and that will tell the story.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
Use REPLY-ALL to reply to list
To unsubscribe from the XROOTD-DEV list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1