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

19991027: Running LDM on Irix 6.5

>From: Erick Lorenz (address@hidden) <address@hidden>
>Organization: UC Davis
>Keywords: 199910272007.OAA03748 McIDAS XCD

Erick,

>I have been trying to get the LDM to run correctly on ATM12, a SGI Origin
>200 running Irix 6.5.
>
>Up till the most recent modification it was collecting DDPLUS|IDS|HRS
>correctly but I was writing to a disk on another machine which I was
>advised was not a good idea.

Right.

>I cleaned off a 4Gb disk on ATM12 called /kapok and created
>a directory called /kapok/data/mcidas.
>
>I then added MCIDAS to the request line of ldmd.conf
>
>   request (MCIDAS|DDPLUS|IDS|HRS) ".*" typhoon.atmos.ucla.edu 
>
>and the following to pqact.conf
>
>MCIDAS  ^(LWTOA3 .*)
>        PIPE
>        -close lwtoa3 -d /kapok/data/mcidas -l /usr/local/ldm/logs/mcidas.log 
> -xv
>
>which is similar to the entry on ATM23 which has been collecting AREA
>files correctly.  Only the -d entry is different to conform to the
>path I want to use on ATM12.

Does this work?

>I still do not understand how the McIDAS-XCD processes know where to
>write their products

McIDAS locates products through file REDIRECTions and MCPATH directories.
XCD, being McIDAS, does the same thing.  There is a set of things that
you should do when setting up XCD for the first time.  Given that you
are going to write to a brand new disk, you are essentially setting things
up for the first time.

>but I knew that they were writing to
>
>       /home/data/mcidas or /home/data/xcd 
>
>which were mount points to a disk on ATM23 so I just dismounted those
>points, deleted them from fstab and created symbolic links in /home/data
>
>lrwxr-xr-x    1 root     sys   18 Oct 26 17:56 mcidas -> /kapok/data/mcidas
>lrwxr-xr-x    1 root     sys   18 Oct 26 17:56 xcd -> /kapok/data/mcidas
>
>This strategy worked fine for the XCD stream.  Those files are updating
>nicely.

OK.

>However the AREA files are not being updated.  They still have the
>dates for when I copied them over from ATM23 eg:
>
>-rw-r--r--    1 ldm      unidata   308528 Oct 26 16:16 AREA0199
>-rw-r--r--    1 ldm      unidata   225088 Oct 26 16:16 AREA0200
>-rw-r--r--    1 ldm      unidata   225088 Oct 26 16:16 AREA0201
>
>Also the ldmd.log file is not being written to but the following
>entries can be found in /var/adm/SYSLOG:
>
>Oct 27 19:31:11 3Q:atm12 pqact[9231]: pipe_prodput: trying again
>Oct 27 19:31:11 3Q:atm12 pqact[9231]: pbuf_flush (6) write: Broken pipe
>Oct 27 19:31:11 3Q:atm12 pqact[9231]: pipe_dbufput: -closelwtoa3-d/kapok/
>data/mcidas-l/usr/local/ldm/logs/mcidas.log-xv write error
>
>and I am seeing the following on the system console.

Sounds like there is a write premission problem on /kapok/data/mcidas.

>Oct 27 18:10:51 pqact[8655]: pipe: execvp: lwtoa3: No such file or directory

I don't understand this one.

>I am also puzzled by the fact that the times shown in the SYSLOG, the
>console and the "ldmadmin watch" display are 7 hours ahead of the
>current time as shown by the date command.

The times are in UTC, not local time.

>The difference is about 
>right for GMT so I could understand it in the ldm messages but not
>in the system messages.

This would depend on how you have the system setup for time.

>The pwd for...

I logged onto atm12 and noticed that you were playing with the LDM.
I verified that logging to ldmd.log was not working, so I can't see
the error messages.  I decided to change the directory permissions
for /kapok/data to 775, and then I noticed that you restarted the LDM.
A quick look at images in the directory shows that they are now being
updated:

cd /kapok/data/mcidas
ls -lt AREA* | more
-rw-rw-rw-    1 ldm      unidata   607856 Oct 27 15:32 AREA0218
-rw-rw-rw-    1 ldm      unidata   225088 Oct 27 15:32 AREA0117
-rw-rw-rw-    1 ldm      unidata   225088 Oct 27 15:32 AREA0116
-rw-rw-rw-    1 ldm      unidata  2422256 Oct 27 15:32 AREA0158
-rw-rw-rw-    1 ldm      unidata   607776 Oct 27 15:29 AREA0069
-rw-rw-rw-    1 ldm      unidata   607776 Oct 27 15:27 AREA0168
-rw-rw-rw-    1 ldm      unidata   225088 Oct 27 15:25 AREA0101
-rw-rw-rw-    1 ldm      unidata   225088 Oct 27 15:25 AREA0100
 ...
date
Wed Oct 27 15:33:18 PDT 1999

So, either changing the directory permissions or something that you were
fiddling with got the image decoding going.

As far as the logging into ~ldm/logs/ldmd.log, I would suggest killing and
restarting syslogd to see if that gets things moving.

>Thank you

Whatever happened to the McIDAS build on the DEC OSF/1 machine?

Tom