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.
Larry Riddle wrote: > > What I've got is DEC3000 and that's what I have to use. There is some talk > that, when a newer, more powerful system (relatively speaking) is replaced > by something even newer and hairy chested, I can replace the current aeolus > with the just retired not-so-new system. Standby for updates. > Are you referring to meteora? We were wondering if meteora was still available and could possibly be pressed back into service. > > No, there is no OEM or VAR hardware support for this machine. The memory > we put in it yesterday was memory that was working fine when it was removed > from machines that are no longer extant at SIO. It worked fine then, but ... > Well then chances are good that the memory was still fine, so that seems to point to the motherboard. > Aeolus died again last night. Before I get all nasty with our over-worked, > one-deep system manager, I'd like to try aeolus for a while in Heisenberg > mode. How do I start the LDM with debug activated? > Well, there are two parts. The first part is slightly tricky, the second part is trivial. First you must figure out which rpc.ldmd process you want to put in debug mode. You currently have 8 of these processes running: aeolus.ucsd.edu> ps -ef | grep rpc.ldmd ldm 2041 1 0.0 08:17:28 ?? 0:00.34 rpc.ldmd -q /usr/local/ldm/data/ldm.pq /usr/local/ldm/etc/ldmd.conf ldm 2044 2041 5.5 08:17:29 ?? 7:40.96 rpc.ldmd -q /usr/local/ldm/data/ldm.pq /usr/local/ldm/etc/ldmd.conf ldm 2045 2041 0.0 08:17:29 ?? 1:34.74 rpc.ldmd -q /usr/local/ldm/data/ldm.pq /usr/local/ldm/etc/ldmd.conf ldm 2060 2041 1.1 08:17:43 ?? 1:55.96 rpc.ldmd -q /usr/local/ldm/data/ldm.pq /usr/local/ldm/etc/ldmd.conf ldm 2097 2041 0.3 08:18:00 ?? 2:04.56 rpc.ldmd -q /usr/local/ldm/data/ldm.pq /usr/local/ldm/etc/ldmd.conf ldm 2105 2041 1.4 08:18:04 ?? 2:07.00 rpc.ldmd -q /usr/local/ldm/data/ldm.pq /usr/local/ldm/etc/ldmd.conf ldm 3490 2041 1.3 08:40:00 ?? 2:15.79 rpc.ldmd -q /usr/local/ldm/data/ldm.pq /usr/local/ldm/etc/ldmd.conf ldm 3491 2041 1.3 08:40:00 ?? 2:10.83 rpc.ldmd -q /usr/local/ldm/data/ldm.pq /usr/local/ldm/etc/ldmd.conf ldm 17680 17665 0.6 11:53:07 pts/3 0:00.02 grep rpc.ldmd aeolus.ucsd.edu> ps -ef | grep rpc.ldmd | wc -l 9 (The ps command above lists 9 because there's always an extra process required to do the 'grep'.) I would suggest putting your main upstream feed in debug mode, the feed from thelma. To determine which rpc.ldmd that is we need to consult the logs. Here's what I do: aeolus.ucsd.edu> cd logs aeolus.ucsd.edu> grep thelma ldmd.log* | grep FEEDME ldmd.log.7:Apr 11 15:17:29 aeolus thelma[2044]: FEEDME(thelma.ucar.edu): OK ldmd.log.crash.2.19:Feb 19 12:41:19 aeolus thelma[118774]: FEEDME(thelma.ucar.edu): OK We want to pick the process ID from the most recent 'OK' that thelma sent in response to the 'FEEDME' request. That would be process ID 2044 from ldmd.log.7. You can see that that corresponds to one of the rpc.ldmds listed in the output from 'ps'. So that's the end of the hard part. Now, just send that process, 2044, a USR2 signal, like this: kill -USR2 2044 Sending it a USR2 signal once puts it in verbose mode. Sending it a USR2 signal again puts in in debug mode. Sending it this signal repeatedly cycles through quiet->verbose->debug->quiet->... etc. modes. So you should execute the 'kill -USR2 2044' command twice. After that, if you want it to go quiet, just issue the same kill command. And, you can confirm that the process got the signal by doing 'ldmadmin tail'. It should say something like "Going verbose", or "Going debug", or "Going quiet". I could easily do this for you now, but I'll let you do it for the experience. I hope this helps! Please keep me posted. By the way, quite an oddity - your email was dated from 4:19AM this morning, but I only saw it after lunch. And, your clock seems fine. I wonder what that's about... Anne -- *************************************************** Anne Wilson UCAR Unidata Program address@hidden P.O. Box 3000 Boulder, CO 80307 ---------------------------------------------------- Unidata WWW server http://www.unidata.ucar.edu/ ****************************************************