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, re: exactly what happened >Sorry for being cryptic! :-) The above is correct, that is, I deleted >all of the old log files, simply did a "touch ldmd.log" - to create a >blank file - and then typed "ldmadmin newlog". What I assume should >have happened is that ldmd.log should have been moved to ldmd.log.1, and a >new ldmd.log file created. This did not happen, nothing changed in the >"logs" directory. OK. The only thing is that an 'ldmadmin newlog' will not rotate the files if ldmd.log is zero length. Creating it with a touch makes it, but it will be zero length. re: group for user running LDM could have changed >That's a good point, the user group id for "ldm" could have changed, >and I checked it out...all looks good. The group id is the same. OK. re: did syslogd have to be restarted? >From the looks of things, syslogd was running just fine. I simply had >the sysadmin restart it. OK. re: quick look around >Sure, if you want to give it a shot, that's great. I'm dumbfounded at >this point: I logged on and found that there are _two_ copies of syslogd running: ldm@dot% ps -eaf | grep syslogd root 1050 1 0 Sep 07 ? 327:28 /usr/sbin/syslogd ldm 8614 8328 0 17:46:00 pts/1 0:00 grep syslogd root 5869 1 0 15:22:55 ? 0:00 /usr/sbin/syslogd This is not good. Your system administrator must have not killed the original one. The fact that /var/adm/messages is not being written to is telling us that the original syslogd is not functioning properly. So, the procedure is to have 'root': o kill both copies of syslogd that are running o start a new copy of syslogd and verify that logs to /var/adm/messages and to ~ldm/logs/ldmd.log I verified that a 'ldmadmin newlog' will work by writing some junk into the zero length copy of ~ldm/logs/ldmd.log and then running 'ldmadmin newlog': ldm@dot% ls -l total 0 -rw-r--r-- 1 ldm craft 0 Oct 14 17:42 ldmd.log ldm@dot% echo lasdfladf > ldmd.log ldm@dot% ls -l total 2 -rw-r--r-- 1 ldm craft 10 Oct 14 17:55 ldmd.log ldm@dot% ldmadmin newlog ldm@dot% ls -l total 2 -rw-r--r-- 1 ldm craft 0 Oct 14 17:55 ldmd.log -rw-r--r-- 1 ldm craft 10 Oct 14 17:55 ldmd.log.1 >Thanks for checking all of this out. This one is a weird mystery! So, it looks like the problem really is being caused by Sun's bug with syslogd. Geez... Tom >From address@hidden Fri Oct 15 08:43:49 1999 re: two copies of syslogd running >Yikes, indeed you are correct! I'll let the system administrator know, >but it might not happen today...I believe he's on his way back from >Seattle. >I'll let you know if that fixes the problem; sounds pretty likely. >Thanks again for all of your help and troubleshooting. Weird problem! Jason