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

20030616: Problem re-starting data filing after upgrade



>From: "Kevin Polston" <address@hidden>
>Organization: NOAA/NWSTC
>Keywords: 200306162216.h5GMG0Ld014327 LDM-6 installation GEMPAK decoding

Kevin,

>I am having a problem with getting data either stored or decoded.  I
>upgraded to nawips5.6j over the weekend and aqlso installed ldm
>6.0.13.

We are not receiving LDM-6 real time statistics from you yet.  Did you
remember to add the 'exec' line to your ~ldm/etc/ldmd.conf file?
Here is what the line should look like:

exec    "rtstats -h rtstats.unidata.ucar.edu"

This should be the last active 'exec' line in your ldmd.conf file.
If you are just adding this line, you will need to stop and restart
your LDM for it to become active.

>It appears that the ldm is running fine and after having moved
>over all necessaary tables and files from my old setup it appeared I was
>ready to go.

Did you install on a new machine?  You shouldn't have had to
change anything with your decoding setup if you simply upgraded from
LDM-5.x to LDM-6.  Note, however, that if you were upgrading from
an LDM-5 version _before_ 5.1.3, you would have had to remake your
LDM queue.

You say that it appears that your LDM is running fine; do you see products
coming in when you run:

ldmadmin watch

>The problem is I am not getting the data saved, decoded or
>stored (at least that's what it seems like).  What's weird is I am
>getting satellite data just fine but metars, upper air, model data,
>profiler data, and miscellaneous data (such as data for plotting watches
>and warnings) are not updating.

It sounds like you did not move "over all necessary tables" correctly.

>I think I have done everything that I
>needed to do (updating or moving the tables, checking permsissions,
>etc).  So I am not sure what the problem is.  I checked a log file for
>profiler data....the message in the log file was "this partiuclar file
>cannot be opened."

I am unfamiliar with the GEMPAK process for decoding FSL wind
profiler data and Chiz is out of town until later this week.  Does
the decoding process write the profiler file (which is netCDF format)
to disk and then tell the GEMPAK decoder where it can be found?

>It seemed the reason it couldn't be opened was
>because it was not there in the data directory where it should have
>been.  So this makes me think it is not getting decoded properly. My
>ldmd.conf and pqact.conf files are the same .....and I believe my
>permissions are ok but I guess I would still have a little doubt there
>(but not much!)

I would check the following:

1) is pqact running (it should be since you are getting images OK)

2) is your pqact.conf file OK.  Verify this by running 'ldmadmin pqactcheck'

3) are only GEMPAK decode actions not working.  If yes, I suspect that
   one or more environment variables related to GEMPAK are not set/
   not set correctly

4) are you _sure_ that the user running the LDM can write to the
   directories that GEMPAK decoders want to write to

>So the question I have is is there anything you can
>suggest I look at or try to do which would verify whether or not I am
>actually receving the data and decoding it or not.

To check if you are receiving the data, run 'ldmadmin watch'.

To tell if data is being decoded, check the various log files.

>Then if it is being
>decoded it should be stored.  Obviously something is "right" as the
>satellite data is coming in just fine and in a timely manner.

OK.  Just as an aside I can say that one can have a pqact.conf file
that has an error in it.  The result of this would most likely be
that the actions before the error will work, and those after the
error will not.  Running 'ldmadmin pqactcheck' will tell you if
you have an error in pqact.conf.

>I copied
>over my datatype.tbl and mod_res.tbl into the new version of nawips to
>keep the changes I had made.  It seems like that went fine as everything
>on the NMAP gui looks where it is supposed to be.  Just no data being
>stored.

Did you, in fact, install on a new machine?

>If we eventually find out it is a simple operator error somewhere then
>lets keep this between ourselves.   :-)

Too late.  All email exchanges go into our inquiry tracking system
which is viewable by the world.  BTW, if you don't want exchanges with
support to show up in the inquiry tracking system, you must request
that they not be put there -- every time you ask a question --.

>Thanks for your help,

I am sorry that I can't pinpoint a GEMPAK configuration error easily
and that Chiz is not around right now.  If I were you, I would
upgrade the LDM on the old system (if you did, in fact, migrate to
a new machine) and verify that everything is working.  If on the
other hand, you upgraded GEMPAK and the LDM at the same time, I
would review the GEMPAK installation steps very carefully.  Again,
upgrade of the LDM does not change anything in the LDM configuration
files ldmd.conf or pqact.conf, so things should keep working as
they had been.  The _only_ things you might have had to do would be:

- delete and remake the LDM queue IF you were upgrading from an LDM-5
  release before 5.1.3

- adjust $hostname, $pq_size, and $numlogs in the new ldmadmin to
  match your setup in the old ldmamdin.  $hostname would have to
  be set to the fully qualified hostname of your machine _if_
  the return of 'uname -n' is not a fully qualified hostname.
  You would adjust $pq_size _if_ you are not using the default
  in ldmadmin.  You would adjust $numlogs _if_ you are not using
  the default in ldmadmin.

Tom