20030423: LDM-6 installations at Lyndon (cont.)

>From: Mark Tucker <address@hidden>
>Organization: Lyndon State
>Keywords: 200304211433.h3LEXd7U002066 McIDAS ADDE compress FreeBSD

Mark,

>I've run into a problem with ADDE requests are not being servered properly.  
>I've pointed clients running mcidasx 7.8 and 2002b to use omega and any adde 
>command returns an error about "stdin: not in compressed format".  I've 
>updated /etc/services and /etc/inetd.conf according to the installation 
>documentation.

re: problems with ADDE under FreeBSD 4.8 may be related to compress

>compress is installed in /usr/bin/compress.  I've tested the utility on the 
>commandline an it works as expected.

OK.

re: I am concerned with the core dump messages

>Omega is running FreeBSD 4.8.  Now you have me worried. 

>What can I check to help debug this problem further?  

Since you say you see the problem when clients point at your new FreeBSD
4.8 box, it would be wise to see if things work while logged on
that machine as 'mcidas' and while trying to access data as LOCAL-DATA.
Here is what I would do:

<login to omega as 'mcidas'>
cd workdata

dataloc.k LIST

What I am looking for is how the 'mcidas' account on omega is setup
wrt where it looks for data.  If the location for the dataset RTIMAGES
is omega.lsc.vsc.edu, I would change it to LOCAL-DATA:

dataloc.k ADD RTIMAGES LOCAL-DATA

After doing this, try the same command(s) that are failing when run
from a client.  For instance:

imglist.k RTIMAGES/GE-IR.ALL

Does this work, or does it cause a segmentation violation?  If this
works, then what happens when you point at the remote ADDE interface
for this same dataset:

dataloc.k ADD RTIMAGES omega.lsc.vsc.edu
imglist.k RTIMAGES/GE-IR.ALL

Does this work (it shouldn't since your other invocations are failing)?

Tom

>From address@hidden Thu Apr 24 07:14:05 2003

On Wednesday 23 April 2003 20:53, you wrote:
> <login to omega as 'mcidas'>
> cd workdata
>
> dataloc.k LIST
>
> What I am looking for is how the 'mcidas' account on omega is setup
> wrt where it looks for data.  If the location for the dataset RTIMAGES
> is omega.lsc.vsc.edu, I would change it to LOCAL-DATA:
>
> dataloc.k ADD RTIMAGES LOCAL-DATA
>
> After doing this, try the same command(s) that are failing when run
> from a client.  For instance:
>
> imglist.k RTIMAGES/GE-IR.ALL

This returns the expected listing when pointed to LOCAL-DATA, no segmentation 
violations in the log files.


> Does this work, or does it cause a segmentation violation?  If this
> works, then what happens when you point at the remote ADDE interface
> for this same dataset:
>
> dataloc.k ADD RTIMAGES omega.lsc.vsc.edu
> imglist.k RTIMAGES/GE-IR.ALL
>
> Does this work (it shouldn't since your other invocations are failing)?

mcidas@omega:~> date
Thu Apr 24 13:09:21 GMT 2003
mcidas@omega:~> imglist.k RTIMAGES/GE-IR.ALL
Image file directory listing for:RTIMAGES/GE-IR
uncompress: /dev/stdin: Inappropriate file type or format
imglist.k: done

From /var/log/messages:
Apr 24 13:09:28 omega /kernel: pid 23754 (adirserv), uid 3054: exited on 
signal 11 (core dumped)

I did have a mismatch between my xcd/pqact entries and my redirections.  I 
corrected these before running any of the tests you suggested.  I still need 
to clean up  the schema and syskey.tab in two locations.

-- 
Mark Tucker
Meteorology Dept. Systems Administrator
Lyndon State College
http://apollo.lsc.vsc.edu
address@hidden
(802)-626-6328