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

[Support #HDQ-517625]: Assistance requested for "Gap in packet sequence" log entries from noaaportIngester

Hi Gregg,

re:
> Correct, there is one SBN/NOAAPORT dish, with the output feeding a
> splitter, and it is my understanding there is an amplifier in front of the
> first splitter.

"the first splitter"?  This suggests that there is more than one
splitter; is this true?

re:
> The output on each splitter has a NOVRA connected to it.

"one each splitter" or on each output port on the one splitter?

I apologize for being a PIA, but I am really trying to fully
understand the setup there!

re:
> On the server with the Gap errors I'm inquiring about I'm using
> nplog_rotate.

OK, my bad.  I thought that I saw the file .scour in the listing
when I was really looking at scour.log.  My apologies!

re:
> On the SPC Operational AWIPS system (a standard installation) with ldm
> running on server cpsbn1/cpsbn2, the LDM is 6.12.14,

OK.  This is typical of a standard AWIPS installation.  We recommend
upgrading the LDM to a current release...

re:
> there is no ~ldm/util directory,

This directory is not created as part of an LDM installation, but
we have recommended having one for years.  One of the reasons for
having a ~ldm/util and/or ~ldm/decoders directory is so that users
NOT be tempted to add executables to the ~ldm/bin directory, and
the reason to never do this is that this directory is actually
a link to the bin directory in the LDM installation being used.

re:
> it doesn't appear the ldm user is running scour either, but the logs are
> handled by a "root" cronjob:

Yup, my bad; see above.

> 
> -bash-4.2$ cd logs
> -bash-4.2$ ls -ltr
> total 2857692
> -rw-r-----. 1 root root          854 Jun 10 21:34 ldmcp
> -rw-rw----. 1 root fxalpha    338842 Jun 14 03:49 polarsat.log-20200614.gz
> -rw-rw----. 1 root fxalpha   6915898 Jun 14 03:49 oconus.log-20200614.gz
> -rw-rw----. 1 root fxalpha  22863506 Jun 14 03:49 nwstg2.log-20200614.gz
> -rw-rw----. 1 root fxalpha   1955940 Jun 14 03:49 goes_add.log-20200614.gz
> -rw-rw----. 1 root fxalpha  56141453 Jun 14 03:49 nwstg.log-20200614.gz
> -rw-rw----. 1 root fxalpha 149441040 Jun 14 03:49 ldmd.log-20200614.gz
> -rw-rw----. 1 ldm  fxalpha     48126 Jun 14 03:50 edexBridge.log.5.gz
> -rw-rw----. 1 root fxalpha  22125540 Jun 15 03:18 nwstg2.log-20200615.gz
> -rw-rw----. 1 root fxalpha    326960 Jun 15 03:18 polarsat.log-20200615.gz
> -rw-rw----. 1 root fxalpha   6656695 Jun 15 03:19 oconus.log-20200615.gz
> -rw-rw----. 1 root fxalpha  54393617 Jun 15 03:19 nwstg.log-20200615.gz
> -rw-rw----. 1 root fxalpha 145304690 Jun 15 03:19 ldmd.log-20200615.gz
> -rw-rw----. 1 root fxalpha   1881407 Jun 15 03:19 goes_add.log-20200615.gz
> -rw-rw----. 1 ldm  fxalpha     46721 Jun 15 03:19 edexBridge.log.4.gz
> -rw-rw----. 1 root fxalpha   6891059 Jun 16 03:34 oconus.log-20200616.gz
> -rw-rw----. 1 root fxalpha    337280 Jun 16 03:34 polarsat.log-20200616.gz
> -rw-rw----. 1 root fxalpha   1948561 Jun 16 03:34 goes_add.log-20200616.gz
> -rw-rw----. 1 root fxalpha  54998377 Jun 16 03:35 nwstg.log-20200616.gz
> -rw-rw----. 1 root fxalpha  22169090 Jun 16 03:35 nwstg2.log-20200616.gz
> -rw-rw----. 1 root fxalpha 147877724 Jun 16 03:35 ldmd.log-20200616.gz
> -rw-rw----. 1 ldm  fxalpha     47842 Jun 16 03:35 edexBridge.log.3.gz
> -rw-rw----. 1 root fxalpha   6619542 Jun 17 03:29 oconus.log-20200617.gz
> -rw-rw----. 1 root fxalpha  21950900 Jun 17 03:29 nwstg2.log-20200617.gz
> -rw-rw----. 1 root fxalpha    333763 Jun 17 03:29 polarsat.log-20200617.gz
> -rw-rw----. 1 root fxalpha  53781865 Jun 17 03:29 nwstg.log-20200617.gz
> -rw-rw----. 1 root fxalpha 144371439 Jun 17 03:29 ldmd.log-20200617.gz
> -rw-rw----. 1 root fxalpha   1927927 Jun 17 03:29 goes_add.log-20200617.gz
> -rw-rw----. 1 ldm  fxalpha     46653 Jun 17 03:29 edexBridge.log.2.gz
> -rw-rw----. 1 root fxalpha    329938 Jun 18 03:08 polarsat.log-20200618.gz
> -rw-rw----. 1 root fxalpha  53836636 Jun 18 03:08 nwstg.log-20200618.gz
> -rw-rw----. 1 root fxalpha   6460733 Jun 18 03:08 oconus.log-20200618.gz
> -rw-rw----. 1 root fxalpha  22164102 Jun 18 03:08 nwstg2.log-20200618.gz
> -rw-rw----. 1 root fxalpha 143532291 Jun 18 03:08 ldmd.log-20200618.gz
> -rw-rw----. 1 root fxalpha   1924537 Jun 18 03:08 goes_add.log-20200618.gz
> -rw-rw----. 1 ldm  fxalpha     46491 Jun 18 03:08 edexBridge.log.1.gz
> -rw-r--r--. 1 ldm  fxalpha   2482323 Jun 18 18:02 scour.log
> -rw-rw----. 1 ldm  fxalpha    321157 Jun 18 20:09 edexBridge.log
> -rw-rw----. 1 root fxalpha   2790279 Jun 18 20:09 polarsat.log
> -rw-rw----. 1 root fxalpha  83793237 Jun 18 20:09 oconus.log
> -rw-rw----. 1 root fxalpha 457339199 Jun 18 20:09 nwstg.log
> -rw-rw----. 1 root fxalpha 258134231 Jun 18 20:09 nwstg2.log
> -rw-rw----. 1 root fxalpha  15890471 Jun 18 20:09 goes_add.log
> -rw-rw----. 1 root fxalpha 945359320 Jun 18 20:09 ldmd.log
> 
> -bash-4.2$

Why are there edexbridge.log files?  Doesn't this indicate that AWIPS
EDEX is running on the machine?

re:
> The server where I'm running the noaaportIngester with the Gap errors is a
> completely different system,

I am getting confused.  Is the listing of log files on your machine
or was/is it for some other machine.  I am not really interested if
it is for another/other machines.

re:
> fed by a different NOVRA box, and the server
> in question is in the satellite farm hooked up directly to the NOVRA box.

I understand that.  That is why I commented that you (your system admin)
can and probably should change the setting in /etc/sysctl.conf to:

net.ipv4.ipfrag_max_dist = 0

re:
> The AWIPS server running LDM is in the server room and the NOVRA box is in
> the satellite farm and there are media-converters to fiber and back to
> ethernet.

This sounds like the same sort of setup as is in use at NOAA/GSL:
The coax from their single NOAAPort dish goes into a "blockhouse"
(brick building in their parking lot), is converted to digital,
sent via a fiberoptic link to the Skaggs building, converted back
into analog and then ** I think ** split and sent to multiple
Novra S300N receivers.  I am not sure about where the splitting is
being done, but it is done somewhere.  I have only had a glance at
the equipment in their "blockhouse", and that was several years ago,
so I can not be certain about their current setup.  I can say that
the two Novra S300N receivers that are in use in the Boulder WFO
are located in a rackmount in a machine room that is just off the
forecast office main area on top of the Skaggs building.  From what
I have been led to believe, the data ingest in the Boulder WFO
has been working well, or, at least, nobody that I have talked to
in GSL knows of any complaints.

re:
> I will try your suggestion on invoking noaaportIngester differently.  I
> don't have root so I'll need to ask one of the two sys admins to do the
> root steps.

Too bad.  Having to get another party involved will naturally slow
down the troubleshooting.  Oh well...

Just so you know, Steve and I are exchanging emails between ourselves
in which we have been discussing your situation...

Cheers,

Tom
--
****************************************************************************
Unidata User Support                                    UCAR Unidata Program
(303) 497-8642                                                 P.O. Box 3000
address@hidden                                   Boulder, CO 80307
----------------------------------------------------------------------------
Unidata HomePage                       http://www.unidata.ucar.edu
****************************************************************************


Ticket Details
===================
Ticket ID: HDQ-517625
Department: Support NOAAPORT
Priority: Normal
Status: Closed
===================
NOTE: All email exchanges with Unidata User Support are recorded in the Unidata 
inquiry tracking system and then made publicly available through the web.  If 
you do not want to have your interactions made available in this way, you must 
let us know in each email you send to us.