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
