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

[LDM #UAK-912261]: data flow problems

Karen,

> Took a while to get everything.  And then they took both radars down for
> a while... always fun to completely stop getting data while you're
> troubleshooting. :-P
> Had me wondering what I'd broken now...
> 
> Here is the result of the lsof command:
> 
> [root@pluto ~]# lsof | egrep "rpc.ldmd.*TCP"
> rpc.ldmd  22002     ldm    0u     IPv4      38231                  TCP
> *:ldm (LISTEN)
> rpc.ldmd  22005     ldm    0u     IPv4      38231                  TCP
> *:ldm (LISTEN)
> rpc.ldmd  22005     ldm    4u     IPv4      38251                  TCP
> 192.168.200.10:33080->192.168.200.4:ldm (ESTABLISHED)
> rpc.ldmd  22006     ldm    0u     IPv4      38231                  TCP
> *:ldm (LISTEN)
> rpc.ldmd  22006     ldm    4u     IPv4      38252                  TCP
> 192.168.200.10:33081->192.168.200.8:ldm (ESTABLISHED)
> rpc.ldmd  22007     ldm    0u     IPv4      38231                  TCP
> *:ldm (LISTEN)
> rpc.ldmd  22007     ldm    4u     IPv4      38254                  TCP
> pluto.protect.nssl:33083->dontpanic.protect.nssl:ldm (ESTABLISHED)
> rpc.ldmd  22008     ldm    0u     IPv4      38231                  TCP
> *:ldm (LISTEN)
> rpc.ldmd  22008     ldm    4u     IPv4      38253                  TCP
> pluto.protect.nssl:33082->towel.protect.nssl:ldm (ESTABLISHED)
> rpc.ldmd  22009     ldm    0u     IPv4      38231                  TCP
> *:ldm (LISTEN)
> rpc.ldmd  22009     ldm    4u     IPv4      38257                  TCP
> pluto.protect.nssl:33084->dontpanic.protect.nssl:ldm (ESTABLISHED)
> rpc.ldmd  22010     ldm    0u     IPv4      38231                  TCP
> *:ldm (LISTEN)
> rpc.ldmd  22010     ldm    4u     IPv4      38258                  TCP
> pluto.protect.nssl:33085->towel.protect.nssl:ldm (ESTABLISHED)
> rpc.ldmd  22017     ldm    0u     IPv4      38271                  TCP
> pluto.protect.nssl:ldm->towel.protect.nssl:35644 (ESTABLISHED)
> rpc.ldmd  22017     ldm    3u     IPv4      38271                  TCP
> pluto.protect.nssl:ldm->towel.protect.nssl:35644 (ESTABLISHED)
> rpc.ldmd  22018     ldm    0u     IPv4      38272                  TCP
> pluto.protect.nssl:ldm->isis.protect.nssl:58544 (ESTABLISHED)
> rpc.ldmd  28788     ldm    0u     IPv4     144503                  TCP
> pluto.protect.nssl:ldm->dontpanic.protect.nssl:48811 (ESTABLISHED)

I'm no lsof(1) expert (I'll defer to Mike) but it seems to me that
the listing shows multiple processes listening on the LDM port
(PID-s 22002, 22005, 22006, 22008, 22009, and 22010).  I didn't
think sockets were supposed to work that way.

The listing also seems to show that Pluto gets two feeds each
from Towel and Dontpanic as well as sending two feeds to Towel
and one each to Isis and Dontpanic.

> Here are the results of ldmadmin watch/notifyme(127.0.0.1) and the
> associated log messages.  They show that localhost connectd, had problem
> with one of the KFDR files -- which actually did show up in the
> notifyme, and then sent KFDR only data for a while.  After about 15
> minutes it started receiving KTLX data also.  As you can see in the
> watch the data comes in from both radars roughly once per minute, but
> the KTLX data just didn't get passed on to the notifyme.
> 
> 
> [ldm@pluto ~]$ ldmadmin watch
> (Type ^D when finished)
> May 29 13:48:52 pqutil INFO:  3275908 20080529133141.627     EXP 000
> /data/2008/05/29/KTLX_RVP.20080529.134731.vcp32.3.lipc.gz
> May 29 13:50:25 pqutil INFO:  3247220 20080529134923.938     EXP 000
> /data/2008/05/29/KFDR_RVP.20080529.134923.vcp32.5.lipc.gz

Regards,
Steve Emmerson

Ticket Details
===================
Ticket ID: UAK-912261
Department: Support LDM
Priority: Normal
Status: Open