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 John, > To: address@hidden > From: "John Hobbie" <address@hidden> > Subject: Slow LDM startup question > Organization: UCAR/Unidata > Keywords: 200509091831.j89IVLnX005071 The above message contained the following: > I have noticed a slow start up of the LDM. It seems to have begun > when we changed from RH9 to Fed C3 some months ago, but may be > unrelated. When LDM is stopped and started again, there is a period of > about 3 minutes where nothing happens. I have attached the data from > the logs. The logs say RPC: Program not regestered. Any suggestions as > to what I may not have set up properly would be appeciated. Other than > the lag, the LDM works fine. > > Thanks in advance for your help, > > Hobbie > National Scientific Balloon Facility > > ==================================ldmd.log================================ > Sep 08 20:07:42 psnldm ldmping[9627] ERROR: SVC_UNAVAIL 0.001287 0 > localhost RPC: Program not registered > Sep 08 20:07:42 psnldm pqcheck[9631] NOTE: Starting Up (9617) > Sep 08 20:07:42 psnldm pqcheck[9631] INFO: The writer-counter of the > product-queue is 0 > Sep 08 20:07:42 psnldm pqcheck[9631] NOTE: Exiting > Sep 08 20:07:43 psnldm rpc.ldmd[9655] NOTE: Starting Up (version: 6.4.1; > built: Aug 23 2005 14:22:26) > Sep 08 20:07:43 psnldm rpc.ldmd[9655] NOTE: Using local address 0.0.0.0:388 > Sep 08 20:10:52 psnldm rpc.ldmd[9655] NOTE: local_portmapper_running(): > clnttcp_create() failure: : RPC: Remote system error - Connection timed out I've seen this problem before. See http://my.unidata.ucar.edu/cgi-bin/getfile?file=/content/support/help/MailArchives/ldm/msg03539.html When checking the see if a pormapper daemon is running on the host, the LDM should get an immediate response from the system rather than have to wait three minutes. It's highly likely that the operating-system is discarding the connection request from the LDM to the portmapper -- resulting in the time-out. The file /etc/sys/config/iptables contains the firewall rules that would cause this behavior. The command iptables -L will list the active firewall rules. You can send the output to us, if you wish, and we'll tell you what's wrong. > Sep 08 20:10:52 psnldm pqact[9664] NOTE: Starting Up > Sep 08 20:10:52 psnldm 172.16.10.76[9666] NOTE: Starting Up(6.4.1): > 172.16.10.76:388 20050908191052.035 TS_ENDT {{FNEXRAD|FSL2|UNIWISC, ".*"}} > Sep 08 20:10:52 psnldm 172.16.10.76[9667] NOTE: Starting Up(6.4.1): > 172.16.10.76:388 20050908191052.129 TS_ENDT {{CONDUIT, "MT\.gfs.*DF.gr1"}} > Sep 08 20:10:52 psnldm 172.16.10.76[9666] NOTE: LDM-6 desired product-class: > 20050908200520.625 TS_ENDT {{FNEXRAD|FSL2|UNIWISC, ".*"},{NONE, > "SIG=e26190f2 > Sep 08 20:10:52 psnldm 192.168.0.101[9668] NOTE: Starting Up(6.4.1): > 192.168.0.101:388 20050908191052.227 TS_ENDT {{ANY, ".*"}} > Sep 08 20:10:52 psnldm 192.168.0.101[9668] NOTE: LDM-6 desired product-class: > 20050908200612.221 TS_ENDT {{ANY, ".*"},{NONE, "SIG=7a2205f016b4894d693656a0 > Sep 08 20:10:52 psnldm 192.168.0.101[9668] NOTE: Product reclassification by > upstream LDM: 20050908200612.221 TS_ENDT {{ANY, ".*"},{NONE, > "SIG=7a2205f016b > Sep 08 20:10:52 psnldm 192.168.0.101[9668] NOTE: Upstream LDM-6 on > 192.168.0.101 is willing to be a primary feeder > Sep 08 20:10:52 psnldm ice[9669] NOTE: Starting Up(6.4.1): > ice.ssec.wisc.edu:388 20050908191052.229 TS_ENDT {{EXP, ".*"}} > Sep 08 20:10:52 psnldm 172.16.10.76[9666] NOTE: Product reclassification by > upstream LDM: 20050908200520.625 TS_ENDT {{FNEXRAD|FSL2|UNIWISC, ".*"},{NONE, > Sep 08 20:10:52 psnldm 172.16.10.76[9666] NOTE: Upstream LDM-6 on > 172.16.10.76 is willing to be a primary feeder > Sep 08 20:10:52 psnldm ice[9669] NOTE: LDM-6 desired product-class: > 20050908200405.955 TS_ENDT {{EXP, ".*"},{NONE, > "SIG=86b41df8835dcc493e16a3f286ef7f57"} > Sep 08 20:10:53 psnldm ice[9669] NOTE: Product reclassification by upstream > LDM: 20050908200405.955 TS_ENDT {{EXP, ".*"},{NONE, > "SIG=86b41df8835dcc493e16a > Sep 08 20:10:53 psnldm ice[9669] NOTE: Upstream LDM-6 on ice.ssec.wisc.edu is > willing to be a primary feeder > Sep 08 20:11:01 psnldm 172.16.10.76[9667] NOTE: LDM-6 desired product-class: > 20050908191101.652 TS_ENDT {{CONDUIT, "MT\.gfs.*DF.gr1"}} > Sep 08 20:11:01 psnldm 172.16.10.76[9667] NOTE: Upstream LDM-6 on > 172.16.10.76 is willing to be a primary feeder > Sep 08 20:12:06 psnldm pqact[9664] NOTE: child 9721 exited with status 127 > Sep 08 20:12:21 psnldm pqact[9664] NOTE: child 9723 exited with status 127 > Sep 08 20:15:42 psnldm pqact[9664] NOTE: child 9782 exited with status 127 > Sep 08 20:16:21 psnldm pqact[9664] NOTE: child 9784 exited with status 127 Regards, Steve Emmerson > NOTE: All email exchanges with Unidata User Support are recorded in the > Unidata inquiry tracking system and then made publicly available > through the web. If you do not want to have your interactions made > available in this way, you must let us know in each email you send to us.