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

Re: 20000614: LDM notifyme and ldmadmin

Matthew Maschmann wrote:

> Anne,
>
> Good morning.  I have an update on our ldm situation.  I have been
> informed that we are not up against a firewall.  I checked the port
> information and have attached it below.
>
>  program vers proto port
>     100000 2 tcp 111 portmapper
>     100000 2 udp 111 portmapper
>     100003 2 udp 2049 nfs
>     100003 3 udp 2049 nfs
>     100003 2 tcp 2049 nfs
>     100003 3 tcp 2049 nfs
>     100024 1 udp 786 status
>     100024 1 tcp 788 status
>     100021 1 udp 2049 nlockmgr
>     100021 3 udp 2049 nlockmgr
>     100021 4 udp 2049 nlockmgr
>     100021 1 tcp 2049 nlockmgr
>     100021 3 tcp 2049 nlockmgr
>     100021 4 tcp 2049 nlockmgr
>     100099 1 udp 2048 autofsd
>     100005 1 tcp 1024 mountd
>     100005 3 tcp 1024 mountd
>     100005 1 udp 1025 mountd
>     100005 3 udp 1025 mountd
>     391004 1 tcp 1025 sgi_mountd
>     391004 1 udp 1026 sgi_mountd
>     100001 1 udp 1027 rstatd
>     100001 2 udp 1027 rstatd
>     100001 3 udp 1027 rstatd
>     100008 1 udp 1028 walld
>     100002 1 udp 1029 rusersd
>     100011 1 udp 1030 rquotad
>     100012 1 udp 1031 sprayd
>     391002 1 tcp 1026 sgi_fam
>     391006 1 udp 1032 sgi_pcsd
>     391009 1 tcp 1027 sgi_pod
>     391029 1 tcp 1028 sgi_espd
>     100083 1 tcp 1029 ttdbserverd
>     391017 1 tcp 1019 sgi_mediad
>     150001 1 udp 782
>     150001 2 udp 782
>     150001 1 tcp 785
>     150001 2 tcp 785
>
>         I also have other news.  Our ldmstart "works" if we comment out
> exec pqact.  I do not think it is really doing anything, but he
> program executes without errors.  Also, we have to specify the exact paths
> of all four exec lines.  Is that normal?  I experimented with those lines,
> and found that specifying the path eliminates some of our errors.
>
>         As far as our file structure goes, is root supposed to own most
> files?  We have made sure that our logs and important files are accesible
> to user, and it does not seem to be an issue.
>
> Thanks,
> Matt
>

> I have a little bit of new information.  I ran the script
>  and got the following output:
>  Jun 15 20:27:07 rpc.ldmd[10974]: Starting Up (built: Jun 14 2000 15:31:10)
> Jun 15 20:27:07 ldmhost[11061]: run_requester: Starting Up: ldmhost.dri.edu
> Jun 15 20:27:07 ldmhost[11061]: run_requester: 20000615192707.527 TS_ENDT 
> {{ANY,
".*"}}
> Jun 15 20:27:07 rpc.ldmd[10974]: bind: 388: Address already in use
> Jun 15 20:27:07 rpc.ldmd[10974]: Exiting
> Jun 15 20:27:07 rpc.ldmd[10974]: Terminating process group
> Jun 15 20:27:07 rpc.ldmd[10974]: child 10917 exited with status 127 l
> Jun 15 20:27:42 ldmhost[11061]: FEEDME(ldmhost.dri.edu): can't contact 
> portmapper:
Timed
> out
> Jun 15 20:28:12 ldmhost[11061]: Exiting
>
> I thought the 388 address already being used was interesting.  Do you know
> what would make that happen??
>
> Matt

Wow, things are changing.  I guess the ldm is finding the portmapper now?  And, 
from
your first message port 388 was not in use, but now, apparently, it is.

The only reason port 388 would be in use is because a previous invocation of 
the ldm
has not released it.  Do a 'rpcinfo -p' again.  I think it will tell you that 
port 388
is in use by the ldm.  Check to see if all the ldm processes are dead ('ps -ef 
| grep
ldm').  If they aren't, kill 'em!  If they are dead but the port is still in 
use, do
'rpcinfo -d 300029' to deregister the port.  (You must do this as user ldm.)

Commenting out the 'exec pqact' in ldmd.conf is a good testing approach.  Even 
if pqact
isn't running you should still be getting products in your product queue.  You 
can test
this with 'ldmadmin watch'.  Also, you can use 'pqcat' to verify that products 
are in
the queue.

No, it is not usually the case that you must give a full path name for pqact.  
Is your
LDMHOME variable set properly?

And, no, it is not the case that root should own most of the files.  I suspect 
that
could cause problems.   The intended environment for the ldm is one in which 
the user
ldm owns the required files and directories, and the ldm is invoked via the 
user ldm.
ldm should own all the files except bin/syshuplog and bin/rpc.ldmd, which are 
setuid
root via make.    Although this may sound onerous, I would advise reinstalling 
the
software as ldm.   (The bright side is, every time you reinstall it it gets 
easier!)
Btw, did you use these instructions in building the ldm:
http://www.unidata.ucar.edu/packages/ldm/ldmSourceInstallList.html  ??  I'm 
assuming
you built it from the source code, is that right?

Is notifyme working for you yet?

Anne

--
***************************************************
Anne Wilson                     UCAR Unidata Program
address@hidden                  P.O. Box 3000
                                  Boulder, CO  80307
----------------------------------------------------
Unidata WWW server       http://www.unidata.ucar.edu/
****************************************************