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