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

20030218: notes on New LDM

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.

  • Subject: 20030218: notes on New LDM
  • Date: Tue, 18 Feb 2003 09:47:39 -0700
  • >from: Steve Emmerson <address@hidden>
  • >keywords: 200302181620.h1IGKY419674
  • >organization: UCAR/Unidata
Carl,

>Date: Mon, 17 Feb 2003 14:41:20 -0700
>From: Linda Miller <address@hidden>
>To: address@hidden,
>To: address@hidden,
>To: address@hidden,
>To: address@hidden
>Subject: Re: New LDM (fwd)

The above message contained the following:

> > At 10:13 AM 2/17/2003 -0600, Carl Sinclair wrote:
> >
> >> Kevin,
> >>
> >> I've been testing LDM6 on the KTLX machine, and it seems to be
> >> running ok. However, the LDM processes died this morning, and I'm
> >> still investigating the cause of this. Also, it locked up port
> >> 388 when that happened and portmapper had to be restarted because
> >> of it.  thought that the new ldm would bypass portmap, so I'm
> >> not sure if this is what I think it is.

LDM-6, like LDM-5, registers itself with the portmapper. This is
to allow connections is situations where the LDM wasn't installed
setuid-root. You can see this by using the rpcinfo(1) utility:

    ~: rpcinfo | grep 300029
    300029    6    tcp       0.0.0.0.1.132       ldmd       superuser
    300029    5    tcp       0.0.0.0.1.132       ldmd       superuser

If LDM-6 terminates abnormally, then it won't be able to deregistered
itself with the portmapper.

When starting and before registering itself, the LDM checks to see if
program 300029 is already registered with the portmapper. If it is, then
the LDM terminates because to continue would be to invite chaos. In this
situation, the solution is to use the rpcinfo(1) utility to manually
deregistered the LDM:

    ~: rpcinfo -d 300029 5
    ~: rpcinfo -d 300029 6

Regards,
Steve Emmerson   <http://www.unidata.ucar.edu>

------- End of Forwarded Message