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.
Hi Erick, Sounds like one of those days! By default, the ldm uses the syslog daemon for logging. In your case, it's the syslog daemon that was continuing to write to that file even after you renamed it. To get it write to the new ldmd.log file it needs to receive a HUP signal. This signal tells the daemon to reread it's configuration file. What's supposed to happen when the logs are rotated is that ldmd.log is moved to ldmd.log.1, a new zero length ldmd.log file is created, then the syslog daemon is hup'ed by calling the ldm program 'hupsyslog'. But, if you restarted the ldm with an empty ldmd.log file in place and nothing happened, then you've moved beyond this problem to a possibly more fundamental one. Here are the pieces that you need for ldm logging to work: - You need one and only one syslog daemon running. Check this with 'ps -ef | grep syslogd'. - There must be a line in /etc/syslog.conf that tells the syslog daemon to write messages from local0 of level debug or greater to the /usr/local/ldm/logs/ldmd.log (or where ever you keep your logs). Confirm that a line like this is in the file: local0.debug /laraine/ldm/logs/ldmd.log (Use tabs between fields - sometimes it won't like spaces.) - The file /usr/local/ldm/logs/ldmd.log must exist. (Hence the need to create the zero length file mentioned above.) - wThe ldm program 'hupsyslog' must be setuid root, i.e., its permissions must be like this: -rwsr-xr-x 1 root ustaff 24041 Dec 5 13:31 hupsyslog* So, check that the above components are in place. Regarding not receiving data, the command notifyme -vl - -h typhoon.atmost.ucla.edu will show you two things. If typhoon has an 'allow' line for your machine in it's configuration, which is what you need so that it will relay data to you, then it will show you all the data that is arriving there. If your syslog daemon got bolluxed up, and something else changed causing you to stop receiving data, it sounds possible that you might be having some system problems. Has anyone checked the system log? (usually in /var/adm/messages) Anne *************************************************** Anne Wilson UCAR Unidata Program address@hidden P.O. Box 3000 Boulder, CO 80307 ---------------------------------------------------- Unidata WWW server http://www.unidata.ucar.edu/ **************************************************** On Fri, 26 Jan 2001, Unidata Support wrote: > > ------- Forwarded Message > > >To: address@hidden > >From: Erick Lorenz <address@hidden> > >Subject: LDM logfiles and server access > >Organization: UCAR/Unidata > >Keywords: 200101262249.f0QMnRX23103 > > I have been running and old installation of ldm (5.0.6) on a machine that > had been retired from that duty (a SGI Indy running Irix 5.3) to tide us > over until I could get Linux reinstalled on the host that is supposed to be > the LDM server (it was invaded). The Indy's LDM is just processing text > data such as FOS. > > This morning it was appearent that it had stopped collecting data. I > thought it might have to do with the power outage at UIUC but I also > noticed that the log file was showed: > > Jan 26 20:01:01 5Q:atm23 typhoon[22134]: run_requester: 20010126190101.349 > TS_ENDT {{DDPLUS, ".*"}} > Jan 26 20:01:01 3Q:atm23 typhoon[22134]: FEEDME(typhoon.atmos.ucla.edu): 7: > Access denied by remote server > Jan 26 20:01:31 5Q:atm23 typhoon[22134]: run_requester: 20010126190131.423 > TS_ENDT {{DDPLUS, ".*"}} > Jan 26 20:01:31 3Q:atm23 typhoon[22134]: FEEDME(typhoon.atmos.ucla.edu): 7: > Access denied by remote server > Jan 26 20:02:01 5Q:atm23 typhoon[22134]: run_requester: 20010126190201.496 > TS_ENDT {{DDPLUS, ".*"}} > Jan 26 20:02:01 3Q:atm23 typhoon[22134]: FEEDME(typhoon.atmos.ucla.edu): 7: > Access denied by remote server > > I contacted the manager at UCLA, James Murakami, who assured me that they > were getting data. He also added the numerical IP address of ATM23 to his > file in case the verbal one was not working. > > I tried again to start the LDM with no luck and then did something which > has made it even more difficult to see what is going on. I noticed that > the log file "ldmd.log" was 0 bytes while the file ldmd.log.1 was getting > larger. I tried to correct this by moving ldmd.log and the four old log > files (ldmd.log.1 to .4) to a subdirctory for archiving and created new log > files with touch. > When I restarted the LDM it still would not write to the log files as > defined in ldmadmin. > > I found that it was still writing to the archived file ldmd.log.1 in the > subdirectory. It is as if the ldm is remembering the inode of the last > file it wrote to and is not paying attention to the file name. I then > copied the archived logfiles to another disk and deleted them. Since then > I have not been able to get the LDM to write to any log file. I have: > > tried changing the name of the default file in ldmadmin. > > tried starting the LDM with and without an empty ldmd.log file in place. > > tried various permutations of the "ldmadmin newlog" command. > > checked the ownership and permissions of the entire path to the log file. > > In the mean time the LDM seems to start ok but when I do ldmadmin watch I > see no incoming files so I assume that it is still being denied. > > My most urgent question is how to get the LDM to recognize and write > messages to its defined log file. > > Thanks > > Erick Lorenz > U C Davis > > > +--------------------------------------------------------------------------+ > | Erick Lorenz, Programmer/Analyst Voice: 530-752-8297 | > | Atmospheric Science FAX: 530-752-1552 | > | Land, Air & Water Resources | > | University of California, Davis e-mail: address@hidden | > +--------------------------------------------------------------------------+ > > > ------- End of Forwarded Message > >