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

19990427: ldm at stc (cont.)

>From: address@hidden
>Organization: St. Cloud State
>Keywords: 199904091934.NAA23884 ldm-mcidas


After I saw this message, I took the liberty of logging onto waldo to
snoop around.  My comments are included below.

>After your message of yesterday, 4/26, we have checked our pqact.conf
>but are having a problem.  Note, we have commented out all lines except
>those dealing with mcidas products for now.  
>The ldm starts ok, but after waiting and checking our log file, we see
>lines such as the following.
>Output from ldmd.log on 4-27-99 for ldm on waldo
>Apr 27 19:50:12 waldo pqexpire[8964]: > Recycled   4867.924 kb/hr (
>1422.365 prods per hour)
>Apr 27 19:55:12 waldo pqexpire[8964]: > Recycled   4803.895 kb/hr (
>1446.684 prods per hour)
>Apr 27 19:57:27 waldo pqact[8966]: pbuf_flush (4) write: Broken pipe
>Apr 27 19:57:27 waldo pqact[8966]: pipe_dbufput:
>-closelwtoa3-d/var/data/mcidas-v write error
>Apr 27 19:57:27 waldo pqact[8966]: pipe_prodput: trying again
>Apr 27 19:57:27 waldo pqact[8966]: pbuf_flush (4) write: Broken pipe
>Apr 27 19:57:27 waldo pqact[8966]: pipe_dbufput:
>-closelwtoa3-d/var/data/mcidas-v write error
>Apr 27 19:57:27 waldo pqact[8966]: child 9197 exited with status 127
>Apr 27 19:57:27 waldo pqact[8966]: child 9195 exited with status 127
>Apr 27 20:00:12 waldo pqexpire[8964]: > Recycled   4789.934 kb/hr (
>1527.129 prods per hour)
>I have checked to make sure that /var/data/mcidas is there, and it is
>owned by ldm, with write permission.

I verified this by doing:

touch /var/data/mcidas/xxx
rm /var/data/xxx

Both worked with no problems.

>I believe the lines in pqact that
>invoke the lwtoa3 decoder are written just as they occur in the example
>pqact.conf we have talked about before, so decided it is time to talk
>with Tom or Don.  What is breaking my pipe?

I logged in as your user 'ldm' and did:

which lwtoa3
no lwtoa3 in /usr/local/ldm/bin /usr/local/ldm/decoders /usr/local/ldm/man /bin 
/usr/bin /usr/ucb /etc /usr/local/bin .

This shows that either you have not yet installed the ldm-mcidas decoders,
or they are in a directory that is not in 'ldm's PATH.

>Note that this ldm (on
>waldo) is feeding from our other machine hobbes.  You have commented
>that hobbes' ldm has some problems with these decoders, but I assume
>the raw products are sent over to waldo, so those problems should not
>be passed over.

You are correct, the original products are fed from one LDM to the next.
The problem appears to be that the decoders are not available.

>Another issue, that I do not think is related, is that I notice the
>lines in pqact.conf specify the full path name when listing where
>products are to be stored, i.e. /var/data/mcidas.   Yet when ldm is set
>up, we create ~ldm/data as a link to a 'volatile' file system.  I
>expected the paths listed in pqact.conf to somehow reflect that link,
>although I can see that listing the full path should work just fine.
>Maybe it is just that we do not want to put items in ~ldm/data.

>Could you comment?

You can either specify a full pathname or a relative pathname for data
product output.  On your system, you have ~ldm/data setup as a link to
/var/data/ldm.  If you wanted to use relative pathnames for ldm-mcidas
created products (e.g. data/mcidas or data/mcidasd), then your McIDAS
data directories would be /var/data/ldm/mcidas and
/var/data/ldm/mcidasd.  As it stands now, you are writing to a
directory that is not a subdirectory of ~ldm/data, so you need to use
full pathnames IF you want the output directory to stay as it is.
There is no harm in keeping things as they are, and there would be no
harm or special advantage in changing the output pathnames to being
relative.  The choice is strictly up to you.

I snooped around quite a bit and could not figure out where you might
have installed the ldm-mcidas package.  I even went so far as to do:

find / -name lwtoa3 -print

This searched every directory under / (the very top level for the disk)
and did not find the AREA file decoder.  I assume, therefore, that you
have not installed the ldm-mcidas package (although you did get the
pattern action example file from the ldm-mcidas distribution and use
it in ~ldm/etc/pqact.conf).

To get you rolling, I decided to grab the binary ldm-mcidas distribution
from our FTP server.  The problem is that this binary was created with
the Sun Workshop compilers and you don't have these.  The second option
was to grab the ldm-mcidas source distribution and build the decoders
on your system

cd /usr/local/ldm
ftp ftp.unidata.ucar.edu
<user = anonymous>
<pass = your email address>
cd pub/ldm-mcidas
get ldm-mcidas.tar.Z

This will be a real test since I have not tried building the ldm-mcidas
package using gcc/f2c on a Solaris x86 system yet.

In order to build the ldm-mcidas decoders from source, however, I have to
install the netCDF package first.

Unfortunately, I have to leave for the night.  I will return and
continue my efforts tomorrow.  I hope my fooling around on your system
is OK with you (please let me know if it isn't!).


Talk to you tomorrow.


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.