Hi JY,
Thanks for the reply! OK, so it seems that I will proceed in the way I
outlined but will provide no default. This would make is compatible with the
way it works today.
Andy
----- Original Message -----
From: "Jean-Yves Nief" <[log in to unmask]>
To: <[log in to unmask]>
Cc: "Andy Hanushevsky" <[log in to unmask]>
Sent: Wednesday, May 04, 2005 6:21 AM
Subject: Re: Proposal to ease running multiple xrootd/olbd pairs on the same
machine
> hello Andy,
>
> Andy Hanushevsky wrote:
>
>> In our xrootd meeting today, we have determined that we need to change
>> the directory naming convention used by xrootd/olbd for administrative
>> files. Curently, the servers create files in /tmp to hold the process ID
>> (i.e., pid files). The xrootd has no problems because it always qualifies
>> it's pid file with it's port number. The olbd does not do so and so that
>> precludes running more than one server and supervisor olbd on the same
>> machine. The problem is worse for the olbd because it also creates
>> management files in /tmp/.olbd and these are not qualified as well. One
>> can get around these problems by explcitly specifying what the paths
>> should be for these files but that is a nuisance and something most
>> people forget until one or the other server can't start up.
>>
>> The xrootd pid file is not particularly important and, in fact, the
>> server goes on it's merry what even if it can't create the file. However,
>> it is useful when one want to figure out who is runniong what on the
>> machine.
>>
>> The olbd pid file is more important since it not only holds the process
>> id but also the local root prefix being used. This information is used by
>> external application to add or remove filename prefixes.
>>
>> So, we need to rethink how directories are named to avoid collisions. I
>> propose adding the "-n <name>" option to xrootd and olbd. The -n option
>> allows you to automatically add <name> as a top-level directory qualifier
>> to all directories used to create admin-type files. So, for instance,
>> "xrootd -n prod" would place the pid file in "/tmp/prod". while "olbd -n
>> prod" would place the pid file in "/tmp/prod" and the special files in
>> "/tmp/prod/.olbd".
>>
>> This introduces a major restriction: The xrootd/olbd pair *must* use the
>> same "-n" argument if they are running as a paired set of servers *and*
>> the xrootd/olbd *must* run using the same username.
>
> this solution is fne by me. The potential drawback that you mention above
> is not a real one according to me: it will force people to do things in a
> "clean" and coherent way and avoid confusion as well. The only thing that
> cannot be done is that one will not be able to run a common olbd for two
> xrootd servers running under two different user account: but I think this
> kind of situation should be unsual: if you run 2 different services, you
> will need also 2 olbd as there is a high probability that the config file
> is going to be different. On top of that, the olbd process are not greedy
> either in term of CPU and memory, so it is not a big deal.
>
>>
>> However, you will be able to start as many xrootd/olbd pairs as you wish
>> as long as each pair is assigned a different "name" using the "-n"
>> option.
>>
>> Now for the hard questions:
>>
>> a) Should there be a default name?
>> One proposal is to use the username as the default name. This introduces
>> a hidden depndency in that if you do not run the xrootd/olbd under the
>> same username, then it won't work at all. Whereas having no default
>> allows them to work if they can work at all. Another proposal is to use
>> the configuration file name as the default (well, atleat up to the dot in
>> the name). This makes sense once you read the next question.
>>
>> b) Should the name be able to be specified in the config file?
>> This makes sense in a way because it's likely that the that each name
>> will have a different configuration file because of connection
>> differences, let alone port number differences.
>
> I like the idea of having a "-n" option and also the possibility to
> specify it using a directive in the config file.
> as for the default name:
> I don't like having the username as the default name. We could be in the
> situation of running 2 services (ie 2 pairs of xrootd/olbd) on the same
> machine for the same experiment under the same account: for example, one
> "read only" service and one "write" service, or 2 services accessing
> different part of the HPSS name space (I have the example with BaBar,
> where I run a service for the CM2 files, the file name in the MSS such as
> /xrootd/store/.... and an other service where users can access their
> private ROOT files: /hpss/in2p3.fr/...., requiring different config
> settings and therefore different pairs of xrootd/olbd).
> At first glance, picking up the default file name from the config file
> name is a simple and nice solution: however in that case, it breaks in
> some sense the consistency in the way of configuring the server through
> the options given at runtime or the directives in the config files. I
> would prefer that everything stay under the control the config parameters,
> it will avoid confusion.
> So at the end, I would be prefer not to have some default name given by
> the user indirectly based on the userid or config file name. If no value
> is specified by the user explicitly ("-n" option, xrootd directive), then
> the value would be given by default by the application itself as it is
> already the case for most of the other xrd/olbd directives.
> is that OK ?
> cheers,
> JY
>
>>
>> Please let me know what you think of this arrangement. Feel free to
>> suggest other alternatives.
>>
>> Andy
>
>
>
