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

20020207: crontabs on aeolus (fwd)

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


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

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

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

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>
  cd unix/780/bugfix
  get mcupdate.tar.Z

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

[ 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

chgrp vumcidas /home/mcidas/.mcenv

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


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


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.


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


Done.  Thanks for your help.


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.