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

20030827: LDM-6 installation at UNCA (cont.)

>From: "Alex Huang" <address@hidden>
>Organization:  UNCA
>Keywords:  200307301533.h6UFXPLd024978 LDM McIDAS upgrade

Hi Alex,

>Wow, you are a genius or what, :-)),

That should be a ;-) (wink).

>thank you so much for helping us out and letting me know what was done.

I'm glad to help.

>I think you did a solid job for us, but I have a few more wishes as follows:

Ready...

>1.    I setup a student account
>for students to use GEMPAK; and another account of
>to use mcidas.   Both are working, so I don't think
>you need to do anything, thank you.

OK.  Please let me know if you would like me to look in on these.  By
the way, is McIDAS installed and run from other machines?  If yes, I
think that those machines should be upgraded to v2003 to match storm2.
Please let me know if you would like me to do this.

>2.    Can you make storm2.atms.unca.edu receive and decode Model data and
>only archive for the recent TWO days?

I just did this for McIDAS.  Do you want me to change the setup for GEMPAK?

>Matt Rosier tried to play with the
>model data in GEMPAK, and I am not sure it is done right.

I see 7 days worth of *.gem model files on storm2, so it looks like Matt
has that setup correctly.  Can the data be accessed from GEMPAK?
If not, the problem is most likely a simple one of where the data is
being output.  Please let me know if you are wanting me to setup
storm2 to decode and keep 2 days of GEMPAK-decoded model data.

re: modifying the LDM boot time startup script to check the LDM queue
integrity before starting, because the queue can get corrupted 

>3.  Actually it happened once (I think), I got the error like "p?q.id exits,
>etc.." while booting, so I deleted that file, and rebooted the machine, and
>it started to work again.  (Lucky me).

What happened in your case was the machine crashed/was stopped and the
LDM was not shutdown properly.  The LDM creates a file ~ldm/ldmd.pid
that contains the process ID of the lead rpc.ldmd.  The LDM startup
procedure checks to see if this file exists, and, if it does, it
complains that things were not shutdown properly.  The fact that things
started OK for you means that the LDM queue was not damaged by the
reboot.

>Do you want to make it dummy (that's me)-proof for the future?  Thanks.

OK.  I will update the startup script to be a little smarter:

- cleanup after an improper stop:

  ldmadmin clean

- check for a viable queue:

  pqcat -s > /dev/null

- delete and remake the queue _if_ it was damaged

  ldmadmin delqueue
  ldmadmin mkqueue

- restart

  ldmadmin start

re: cron jobs that produce different maps

>4.    I agree that cron jobs need to be placed in a permanent directory, I
>think I can ask Bob Benites to do it, but if you have 10 minutes, can you do
>it for me?

Done.  I put the C shell scripts in the ~ldm/util directory.  I also added
this directory to the PATH for 'ldm' (in .cshrc), and added /home/ldm/util
to the PATH sepecification in the contab file.

>Will /ldm/util be a good place for it?

Yes, absolutely.  This is exactly what the util directory is good for.

>Do you think it may
>loose the link if it is moved to other directory?

No, I think everything will be OK.

>5.    I think I am done with my wishes for now, thank you again.  I really
>appreciate it.

No worries.

>Have a virtual beer until we meet again. :0))

Since you are (virtually) offering, I'll have two ;-)

Tom