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.
>From: "Jason J. Levit" <address@hidden> >Organization: Center for Analysis and Prediction of Storms, University of Okla homa >Keywords: 199910111619.KAA28000 LDM syslog Jason, >Welp, I gave all of the above a try, and nothing seems to work. The LDM >configuration and the system have not changed at all, and I had our >sysadmin restart syslogd, to no avail. "ldmadmin newlog" just doesn't >seem to work anymore. No errors, no clues. > >Do you have any other suggestions on where I can look? Is there a way >I can debug this? Your reply did not tell me whether or not 'ldmadmin newlog' created a new ldmd.log file. I am assuming that ""ldmadmin newlog" just doesn't seem to work anymore" means no, but I am not 100% sure. If this is not creating a new ldmd.log file, then my guess is that somehow the file permissions are such that the user running the LDM is not allowed to delete files in the ~ldm/logs directory. This can happen in a way that looks mysterious: the group of the user that runs the LDM gets changed, but the log files themselves do not get their ownership changed. A quick listing of the files might make it look like 'ldm' owns them, but if the group that 'ldm' is in changed, then the current 'ldm' might not have write permission. I have seen this kind of thing in other contexts, so that is why I offer it. One other question, did syslogd have to be started (i.e. had it died or was it locked)? > Thanks for your help. I would be happy to take a quick look around if you provide me with the login of the user running the LDM and the machine that the LDM is running on. Tom