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