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.
>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