[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 20000915: ROUTE PostProcessing setup at Oregon State (cont.)

This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.

  • Subject: Re: 20000915: ROUTE PostProcessing setup at Oregon State (cont.)
  • Date: Tue, 19 Sep 2000 09:48:22 -0600
Wayne,

I understand the constraints regarding various "local" syslog facilities
already being allocated to other applications.  If you build the LDM from
source, it looks like modifying ulog/ulog.h to use some other facility
would be a possible workaround.

mike

On Sep 18,  2:06pm, Wayne Gibson wrote:
> Subject: Re: 20000915: ROUTE PostProcessing setup at Oregon State (cont.)
> Mike,
>
> We've had to be a bit more ruthless.
>
> "local0.debug" on all college wide computer systems is already being used.
>  My hands are tied there.  So syslogd is of no use.
>
> The most direct option I could think of was to direct the output by using the
> "-l" switch in all calls to "rpc.ldmd".  As a result, I've had to modify
> ldmadmin and our method of rotating logs.  So now every 6 hours, I call a
> Bourne shell script with the following :
>
> logfile=/home/ocs/ldm/logs/ldmd.log
> nback=4
> bin/ldmadmin stop
> bin/newlog $logfile $nback
> bin/ldmadmin start -v
>
> ldmadmin is never called to rotate the logs, just to stop and start ldm.
>
> If you have a more elegant solution, I'd be more than happy to implement it.
> As you can see in the next line, we need to upgrade our OS.  Tom and I have
> already discussed this in reference to the new version of ldm
> ...