[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Aeolus Again

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/
****************************************************