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

20021125: pqing and pqact not writing to ldmd.log

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: 20021125: pqing and pqact not writing to ldmd.log
  • Date: Wed, 27 Nov 2002 08:55:08 -0700
Jeff,

>Date: Tue, 26 Nov 2002 11:12:49 -0500
>From: Jeff Ator <address@hidden>
>Organization: NOAA/NWS/NCEP
>To: Steve Emmerson <address@hidden>
>Subject: Re: 20021125: pqing and pqact not writing to ldmd.log

The above message contained the following:

> (1)  The ldmd.log file does indeed exist, as you've probably already guessed
> from the fact that the output of the below ulogger command showed up there!
> ;-)
> 
> (2)  We are not running a full LDM where, e.g. we use rpc.ldmd to communicate
> with and exchange data with other LDMs.  Rather, we have our own
> communications software and are only using the LDM queueing mechanism in
> order to interface with our decoder software.  In other words, our comms
> software directly calls pqing to ingest data into the LDM queue, and we run
> pqact as a daemon to read data out of the queue and EXEC the necessary
> decoders.  Under previous versions of the LDM we also ran pqexpire, but,
> since the release notes for version 5.1.4 indicate that we shouldn't need to
> do that any longer, we have turned off that cron job.  In summary, the only
> things that we would expect to write to ldmd.log are pqing and pqact, since
> those are the only "pieces" of the LDM software that we are using.
> Nevertheless, we did fully compile everything (i.e. the entire LDM package)
> according to the instructions, so if there are any tests that you would like
> us to try (such as the below command that we ran using ulogger!), we can do
> that.

Because the ulogger(1) utility uses the same ulog(3) library that
pqing(1) and pqact(1) do, The fact that it works and the others don't
indicates that one or more assumptions are incorrect.  One of the
assumptions is that the same ulog library is linked to ulogger and
pqing.  I know, for example, that some operating systems allow for
dynamic linking of libraries based on the values of certain environment
variables.

You'll have to investigate.  Try the following:

    1.  Run ulogger and pqing manually, logging to standard output.  Do
    they work correctly?

    2.  Run them manually but logging directly to a file.  Do they work
    correctly?

    3.  Modify /etc/syslog.conf so that "local0" messages go to a file.
    Execute ulogger and pqing manually.  Do they log correctly?  If so,
    then either the pqing that you executed isn't the same as the one of
    the batch job, or there's something in the environment of the batch
    job that causes it to misbehave.  Check the log files of the pqing
    build process to see what libraries were linked to it.

Let me know what you discover.

Regards,
Steve Emmerson   <http://www.unidata.ucar.edu>