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.
Unidata Support wrote: > > ------- Forwarded Message > > >Subject: ldm problems (Anne and Tom) > >Organization: UVa > >Keywords: 200102012128.f11LSdX24812 LDM McIDAS ROUTE PP > > Anne, and maybe Tom too, > > There still seems to be some problems with the ldm. > The log is once again filling up with error messages, > and the mcidas log is showing that batch.k cannot be > found. I think we still need to have a correction to > the PATH in the /usr/local/ldm/util/batch.k script, > but maybe I am wrong. > > I am also puzzled by the fact that once again the ROUTEPP.LOG > file is owned by ldma, although Anne indicated she had > changed it. > Hello Jennie, The comment about ROUTEPP.LOG made me realize my mistake. Although I set up the crontab table for ldm, I neglected to turn off the cron jobs for ldma. I apologize for this. Of course, this caused significant problems and confusion. I have now commented out everything in ldma's crontab. This is why ROUTEPP.LOG got removed and recreated by ldma. I had also forgotten to change some paths in the ldmd.* configuration files for the failover, which also caused some confusion. I think this fixed the problem that appeared to be that batch.k wasn't found. Really, instead of batch.k not being found, I think that batch.k wasn't finding something it needed, somehow related to ROUTEPP.LOG. I don't fully understand that, but it seems to be working now. > Another weird thing, that Anne had mentioned, is that > when I start the ldm diagnostic notifyme, there is no way > to stop it short of killing the process? And, for navier, > as Anne noted, it just shows NEXRAD-related stuff. > I'll need to look into both of these issues further. > If PennState went down and then came back up, we have > had problems in the past where we resume getting IDD/DDPLUS > data but nothing from the McIDAS feed- I don't think that > has ever been resolved. But given the errors in the logs, > it seems something else is wrong on my end anyway. > I note that the last imagery I seem to have received > was from 17Z yesterday, and yet the log reset (occurred > at 18:50Z yesterday (with automatic failover, what > initiates a log-reset? ) > Again, I suspect this is a problem initiated by ldmfail running out of the ldma crontab at a time when navier was down... This is a guess. Let's see what happens. Also, Tom and I thought it would be better if mcidas.log was rotated rather than being simply removed, so we modified ldm's crontab to rotate 2 logs. Of course, you can change this if it's not what you want. > Once again, I am uncertain of what to do, I could change > the ownership of ROUTEPP.LOG to ldm, and I could add > to the PATH in the _script_ batch.k to include > /usr/local/ldm/bin/ldm-mcidas, but I am not sure if these > would solve whatever is going wrong. I am not sure how to > see if navier is getting/sending mcidas data. > I think things are ok now. I will check again later. > Sorry to continue to be the source of problems, especially > when I can see from the mail that there has been a flurry > of questions today. > Nope, you're not the source of the problem, I was. I apologize. I'm embarrassed about the crontab problem... > befuddled, > > Jennie > > ------- End of Forwarded Message Hope this eases your fuddlement. Anne -- *************************************************** Anne Wilson UCAR Unidata Program address@hidden P.O. Box 3000 Boulder, CO 80307 ---------------------------------------------------- Unidata WWW server http://www.unidata.ucar.edu/ ****************************************************