This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
Sitler Jeffrey L Civ AFIT/ENP wrote: > > Hi Anne, > I noticed you sent me an email at 630 our time. Our system was down for work > from 6-7 so I am guessing that was the problem. I just tried to log in as > ldm, and I had no problems. > Hope you had a good evening. > Thanks > Jeff > Hi Jeff, Yes, that must've been it. I think logging is straightened out now. The ldm is logging to ~ldm/logs/ldmd.log and those logs are being rotated. Also, syslogd is logging to /var/adm/messages and ldm messages are not going there. That log has not yet been rotated. If it gets too big we'll need to look into it's rotation. The file /var/tmp/wsconAAAp.aG3b:0.0 is still growing, but ldm messages are not being put there. In looking at the head of that file, it looks like a log from lmgrd, a license manager deamon. That file is bloated in large part because of ldm messages that are now moot. It's possibile that you could simply remove the file, and it will be restarted when the deamon runs again. (I think that deamon runs when someone starts up an application that requires a license, but I know very little about it. I'll defer to your own sys admin for that one.) > I did leave things in the data directory/file for a week. I just cleaned > that out yesterday. > 7 days of data will sit without bringing the drive to 100%. So once we get > to scour we are going to hold for 7 days then delete. > Yes, space seems fine, judging from the past week or so. It looks like you went through a period of bad connectivity from 1:40Z this AM to 9:40Z - see the logs. You lost some products that were too old by just a minute. If this gets to be a problem, we can increase the default latency value. Also, it looks like for a while your name server was failing - the ldm couldn't contact striker.atmos.albany.edu, but that seems to be resolved now. I'm not seeing any more errors from dcgrib - I wonder what changed? In fact, the logs from the decoders are looking pretty good for the last 24 hours. Also, it is worthwhile to check ldm's mail periodically, if not regularly. That's where cron will report problems. If you look there now, you'll see the problem regarding the mailhost. Do you want to turn off stats until the mailhost problem is fixed? You don't have to. One benefit of having the stats files is that you can see information about the data your getting and its timeliness. I also meant to tell you that I modified the 'path' variable in ldm's .cshrc script. (The old script is still available in .cshrc.save.) This fixes the path to the various ldm executables. In general, I think your ldm is in pretty good shape at this point. I will stop checking it now. Please let me know if you see any further problems. And, if you have problems pertaining to gempak and/or decoders, send them to support@unidata, where they will most likely be forwarded to Steve Chiswell. Anne -- *************************************************** Anne Wilson UCAR Unidata Program address@hidden P.O. Box 3000 Boulder, CO 80307 ---------------------------------------------------- Unidata WWW server http://www.unidata.ucar.edu/ ****************************************************