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

20021023: Processes hang when accessing ADDE server at USU (cont.)

>From:  "Rob Gillies ." <address@hidden>
>Organization:  USU
>Keywords:  200210222244.g9MMiEp01962 McIDAS ADDE LDM ldm-mcidas

Hi Rob,

>Tom - the information I was requesting was located locally on Allegan. So you 
>can point to Allegan like you did in class and see if you receive the
>requested data.

I pointed at allegan for images in the RTIMAGES dataset group, and got the

DSINFO: Cannot contact server (connect() failed)
    No Datasets found of Type: IMAGE in Group: RTIMAGES
DSINFO -- done

This tells me that the problem you are seeing is either with the ADDE
remote server setup on allegan.nr.usu.edu or access to allegan.
(Note: while I was writing this email, ADDE access to allegan started
working.  I will leave in the troubleshooting comments I wanted to
make when there was no access mainly so they get put into our
inquiry tracking system.)

I notice that someone at USU downloaded both the 7.8 and 2002
distributions of McIDAS recently (yesterday and today, respectively).
While reloading McIDAS or upgrading to a new distribution can't hurt,
it is probably not necessary in this case.

What we need to determine is why access to the remote ADDE server on
allegan suddenly is no longer available.  Some possibilities are:

o the file ~mcidas/.mcenv got damaged or deleted

o the contents of /etc/services and/or /etc/inetd.conf got changed
  (these files contain system definitions for the ports that ADDE
  will use and the program that needs to be run by inet when a
  request comes in on either of the ports that ADDE uses)

o security on the net (e.g., a firewall) was changed, and the change
  is now blocking access to allegan on port 500 and/or 503

The way I typically test to see if McIDAS ADDE is listening on either
port 500 or 503 is by using telnet (this is crude, and subject to
the telnet service being turned off).  Here are the tests that I
run and their results:

1) to the port used for uncompressed ADDE transfers:

   telnet allegan.nr.usu.edu 500
   Escape character is '^]'.
   ÿprotocol version mismatch:client wants 1634493546, server knows 1       
Connection to allegan.nr.usu.edu closed by foreign host.

2) to the port used for compressed ADDE transfers:

   telnet allegan.nr.usu.edu 503
   Escape character is '^]'.
   ÿprotocol version mismatch:client wants 1818325867, server knows 1       
Connection to allegan.nr.usu.edu closed by foreign host.

In both cases, the sequence 'laskdjflajd' is just some random letters
I typed in to evoke a response from the ADDE remote server.

So, the remote server is now accessible to me from may machine at the
UPC.  The next thing I did was to rerun the DSINFO command I listed


        Dataset Names of Type: IMAGE in Group: RTIMAGES

Name         NumPos   Content
------------ ------   --------------------------------------
ANTARCTIC       10    Antarctic IR Composite
EDFLOATER-I     10    Educational Floater
EDFLOATER-II    10    Educational Floater II
GE-IR           10    GOES-East North America IR
GE-IRTOPO       10    GOES-East IR/TOPO Composite
GE-VIS          10    GOES-East North America VIS
GE-VISTOPO      10    GOES-East VIS/TOPO Composite
GE-WV           10    GOES-East North America H2O
GEW-IR          10    GOES-East/West IR Composite
GEW-IRTOPO      10    GOES-East/West IR/TOPO Composite
GEW-VIS         10    GOES-East/West VIS Composite
GEW-VISTOPO     10    GOES-East/West VIS/TOPO Composite
GEW-WV          10    GOES-East/West H2O Composite
GW-IR           10    GOES-West Western US IR
GW-IRTOPO       10    GOES-West IR/TOPO Composite
GW-VIS          10    GOES-West Western US VIS
GW-VISTOPO      10    GOES-West VIS/TOPO Composite
GW-WV           10    GOES-West Western US H2O
MDR             10    Manually Digitized Radar
MDRTOPO         10    MDR/TOPO Composite
MOLL-IR         10    Mollweide Composite IR
MOLL-IRTOPO     10    Mollweide IR/TOPO Composite
MOLL-WV         10    Mollweide Composite H2O
RESFLOATER      10    Research Floater

DSINFO -- done

This tells me that the ADDE server is correctly setup to list its
setup for the RTIMAGES dataset.  The the next step is to see if
the server can find data files:

Image file directory listing for:RTIMAGES/GW-IR
IMGLIST: No images satisfy the selection criteria
IMGLIST failed, RC=2

Now we are making progress.  This is telling us that the images that
are supposed to make up the RTIMAGES/GE-IR set can not be found by
the remote server on allegan.  This means one of two things:

o the images are not there -> they are not being decoded correctly
  (since you say your LDM is receiving the data)

o the images are being decoded, but are no longer accessible from
  the 'mcidas' account.  This could be due to their being in a
  different file system, or by the set of file REDIRECTions used
  by the user 'mcidas' having been altered/deleted.

The thing to test now is:

<login as 'mcidas'>
cd workdata
dmap.k AREA

Does the 'dmap.k AREA' invocation list back any files?  If not, it means
that the files are no longer there and/or are in a different place.
Again, if the listing is empty, continue to probe:

redirect.k LIST

Are there entries for AREA files in the listing?  These would look something

AREA006*     /var/data/mcidas
AREA007*     /var/data/mcidas

The listing pairs are a regular expression for a set of AREA files and
the directory in which to find them.  The directory you are using
will likely be different from the two listed above.

Again, if you have REDIRECTions in place, you will see where McIDAS is
trying to find the AREA files.  Use the Unix 'ls' command to see if
the images are, in fact, there.  For example:

ls /var/data/mcidas/AREA*

Now, if the images are not there, it means that the decoding of the
products being received by the LDM has stopped or is failing.  To
see if this is the case, you should look through the log file
you are using for outputting of messages from the ldm-mcidas PNG
compressed AREA file decoder, pnga2area (check ~ldm/etc/pqact.conf
to see where this might be; if no log file is specified, the log
messages will be in ~ldm/logs/ldmd.log*).

OK.  That is probably enough for one email message.  Please let
me know what you find.

* Tom Yoksas                                             UCAR Unidata Program *
* (303) 497-8642 (last resort)                                  P.O. Box 3000 *
* address@hidden                                   Boulder, CO 80307 *
* Unidata WWW Service                             http://www.unidata.ucar.edu/*

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.