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

20020821: Disk Full - XCD_START.LOG not closing

>From: Mike Voss <address@hidden>
>Organization: SJSU
>Keywords: 200208211540.g7LFerK22645 McIDAS xcd_run

Mike,

This is a quick follow-up note to the one I sent earlier today.

I rebuilt and reinstalled McIDAS-X, -XCD on metsun1 this morning.  I
did this after updating the code with the latest 7.8x addenda.
After doing the complete rebuild and reinstall, I also:

o deleted and remade the DECINFO.DAT file in ~mcidas/workdata.  This
  is used to control which XCD data monitors will run

o stopped and restarted the LDM to force the newly built XCD binaries
  to be used in stead of the old ones

o removed duplicate copies of ROUTE.SYS and SYSKEY.TAB from the
  /data3/mcidas/xcd and /data3/mcidas/mcidas directories (I hope
  I am naming the last directory correctly).  Both XCD and ldm-mcidas
  decoders can/will write to these files, and they need to be
  the same regardless of which decoder is writing to them.  I 
  accomplished this by deleting the copies in /data3/mcidas/xcd
  and linking the ones in /data3/mcidas/mcidas to /data3/mcidas/xcd.
  While at it, I also linked SCHEMA between the same directories

After watching LDM ingestion and XCD decoding for awhile, I saw no problems
so I logged off.

As a parting thought, I will add the following:

Your problem was that dmsfc.k was getting a segmentation violation and
exiting.  The XCD supervisory routine startxcd.k (run by the 'exec
xcd_run MONITOR' action in ~ldm/etc/ldmd.conf) is responsible for
restarting all data monitors that are supposed to be active.  When a
data monitor gets restarted, a new log entry is written.  If the data
monitor has a problem (like yours did), it exits and gets restarted
frequently, thus causing a lot of log output.

Since XCD_START.LOG will continually be written to, it could eventually
grow to be quite large IF the LDM and XCD ran with no errors for a LONG
time.

Since XCD_START.LOG is continually open for writing, one can not simply
delete it and expect things to work (this, in fact, was the bug that
I corrected in xcd_run).  What can be done, however, is copy /dev/null
to the file at regular intervals.  This has the desired effect of
zeroing the file while still keeping it open/viable.  What I have in
mind is running the following from cron:

cat /dev/null > /export/home/mcidas/workdata/XCD_START.LOG

This could be done once per week for systems that are running smoothly
or more frequently for systems experiencing problems (but, one would
typically want to find and fix the reason for the problems).

Let me know if you see the problems related to XCD_START.LOG return.

Tom

>From address@hidden Wed Aug 21 12:44:10 2002
>Subject: Re: 20020821: Disk Full - XCD_START.LOG not closing 

Tom,
As always your help is much appreciated, thanks!!  I added to cron that
"cat of /dev/null to the log" just to be safe for the time being.

I have learned a good lesson, which I seem to need to learn over and
over again...when in doubt... "LOOK INSIDE THE LOG FILE"

cheers,
Mike