Re: 20000919: LDM code modification change request

>cc: address@hidden,
>cc: address@hidden
>From: Wayne Gibson <address@hidden>
>Subject: Re: 20000919: ROUTE PostProcessing setup at Oregon State (cont.)
>Organization: Oregon State University
>Keywords: 200009142249.e8EMnCb02002 LDM ldm-mcidas batch.k

Hi Wayne,

> Is it possible to modify the source code such that the unit to log on
> could be specified in the ldmd.conf file.  For example, at our site
> "local1" is available and if there was some way that could be specified
> in ldmd.conf, then an HUP signal would work and no modifications of
> source code or ldmadmin would be required.  In theory, this could be a
> permanent "enhancement" to the ldm system.

It would be possible to change the LDM to use a different facility
than LOG_LOCAL0 for logging, as you have found necessary since your
campus already uses LOG_LOCAL0 for other purposes.  There are 7 other
possibilities to choose from: LOG_LOCAL1, ... LOG_LOCAL7.

However, specifying which logging facility to use in ldmd.conf would
require that other LDM programs that have to use the same logging
facility know how to parse ldmd.conf, in particular the scour script
and all the other LDM programs that run concurrently with rpc.ldmd,
such as pqact, etc.

If an environment variable were used instead of some syntax in
ldmd.conf, then it would be relatively easy to make sure all LDM
programs use the environment variable instead of knowing how to parse
the ldmd.conf file.  And it's relatively easy to arrange that the
"ldm" user's environment variables get set consistently for processes
that need to be started at boot time, if these are started in the way
we recommend (a script in /etc/init.d/ldmd which starts the processes
with "su - ldm", which makes sure ldm's .cshrc or .profile is read to
set up the necessary environment variables).

So I propose to just make the change to ulog/ulog.c, to have the
openulog() function, called by all of the LDM programs, detect whether
the environment variable LDM_LOG_FACILITY is set, and if so to use it
to override whatever log facility openulog() was called with.  This
would be a relatively small change that would be backward compatible
with the current behavior.  It would require that you set this
environment variable to one of the values 1, 2, 3, ..., 7 in ldm's
.cshrc (or .profile if your ldm uses a different shell).  We could
also add code to the scour script to detect whether this environment
variable is set and use it to override the logging facility.  Or
rewrite scour in C to use the openulog() function.

This seems like a good suggestion, so I'll put it on my list.  I may
send you the modifications to ulog.c and the scour script for testing.

--Russ