20020207: crontabs on aeolus (fwd)

>From: William C Klein <address@hidden>
>Organization: Valparaiso
>Keywords: 200202061926.g16JQSx10267 McIDAS-XCD McIDAS LDM

Bill,

I got onto aeolus and started looking around to see why you were
getting xcd_run invocation error messages in the LDM log file.  Very
quickly I discovered that none of the McIDAS executables could be
executed.  Here is an example of me attempting to run decinfo.k:

<login as 'mcidas'>
cd workdata
decinfo.k

ld.so.1: decinfo.k: fatal: relocation error: file decinfo.k: symbol 
__s_rsFe_pv: referenced symbol not found
Killed

Was an update to the OS done on aeolus recently?  Something has sure changed
since McIDAS was built.

Given the execution failure, it is no wonder that you were getting the
xcd_run error messages in the LDM log files!  This is because the LDM
runs xcd_run which, in turn, runs either ~mcidas/bin/startxcd.k (xcd_run
MONITOR option), ~mcidas/bin/ingetext.k (xcd_run DDS option), or 
~mcidas/bin/ingebin.k (xcd_run HRS option).  None of the McIDAS executables
were executable (all gave the same error message as decinfo.k gave above),
so errors were generated by pqact and saved in the ~ldm/logs/ldmd.log
file.

Since the Sun C and Fortran compilers seem to be in the appropriate spot,
I decided to see if rebuilding McIDAS from source would set things right.
Before doing this, I downloaded the latest McIDAS addendum (January 3)
and then rebuilt:

<as 'mcidas'>
cd mcidas7.8/update
ftp ftp.unidata.ucar.edu
  <user for distribution>
  <pass>
  cd unix/780/bugfix
  binary
  get mcupdate.tar.Z
  quit
./mcunpack

cd ../src
make clobber
make all
make install.all

After rebuilding, the McIDAS executables were once again executable.

While at it, I decided to resetup the XCD decoding and ADDE serving
on aeolus.  This included (all done as 'mcidas') and was done while
the LDM was not running:

o cd ~mcidas/workdata
  rm *.DAT

  <verify that the McIDAS string XCDDATA pointed to the XCD decode directory>
  tl.k XCDDATA

  batch.k XCD.BAT
  batch.k XCDDEC.BAT

o cd ~mcidas/data
  cp DSSERVE.BAT LSSERVE.BAT
  <edit LSSERVE.BAT and remove datasets that aeolus does not have/will not
  serve.  Also change the RTNEXRAD configuration file from NNEXRAD.CFG
  to VALPNEXR.CFG (this already existed in ~mcidas/workdata)>

o cd ~mcidas/workdata
  rm RESOLV.SRV
  batch.k LSSERVE.BAT

After doing the above, I restarted the LDM and verified that data was being
ingested, filed, and decoded.

Now, I was going to setup logging of ADDE server transactions on aeolus,
but I ran into problems editing ~mcidas/.mcenv.  This file is owned by
'mcadde', and 'mcadde' is shown to be in the same group as 'mcidas' and
'ldm':

[ 129 ] > id mcadde
uid=103(mcadde) gid=100(vumcidas)
[ 130 ] > id mcidas
uid=102(mcidas) gid=100(vumcidas)
[ 131 ] > id ldm
uid=101(ldm) gid=100(vumcidas)

The problem is that a long list of ~mcidas/.mcenv shows that it is owned
by 'mcadde', but the group is 'other':

[ 132 ] > ls -alt .mcenv
-rw-rw-r--   1 mcadde   other        488 Mar 23  2001 .mcenv

This tells me that the group for 'mcadde' has apparently changed since
.mcenv was created.  'root' should now change the group of .mcenv to
vumcidas:

chgrp vumcidas /home/mcidas/.mcenv

After this is done, I can setup ADDE server logging by adding the following
lines to it:

ADDE_LOGGING=YES
export MCHOME MCDATA MCPATH MCTABLE_READ MCTABLE_WRITE PATH ADDE_LOGGING

I already added rotating of the ADDE log files to the crontab of 'ldm',
so that part is finished.

Also while poking around to setup ADDE logging, I noted that stats
files generated by the LDM were not getting scoured from ~ldm/logs
(there were thousands of *.stats files in that directory).  I deleted
the old files and setup sending of the stats files to Unidata.  This
was done by adding a 'ldmadmin dostats' action to cron for 'ldm'.

Synopsis:

Things appear to be working on aeolus again.  Please let me know when you
have changed the group for ~mcidas/.mcenv.  When that is done, I will
finish setting up ADDE logging.

Tom

>From address@hidden Fri Feb  8 14:16:29 2002
>Subject: Re: 20020207: crontabs on aeolus (fwd) 

Tom,

Done.  Thanks for your help.

Bill