Due to the current gap in continued funding from the U.S. National Science Foundation (NSF), the NSF Unidata Program Center has temporarily paused most operations. See NSF Unidata Pause in Most Operations for details.
Due to the current gap in continued funding from the U.S. National Science Foundation (NSF), the NSF Unidata Program Center has temporarily paused most operations. See NSF Unidata Pause in Most Operations for details.
Steve Emmerson wrote: > > Jim, > > >Date: Thu, 17 Oct 2002 14:36:42 -0400 > >From: Jim Koermer <koermer@xxxxxxxxxxxxxxxxx> > >To: ldm-users@xxxxxxxxxxxxxxxx > >Subject: LDM Problems > > The above message contained the following: > > > However, Murphy's Law seems to be ringing true and I've detected new > > problems that I had not encountered before. The first problem is that > > for some reason, I will have duplicate LDM processes running--one set > > owned by ldm (as it should be) and the other set of one or more > > processes owned by root (which should not be the case). I can't find any > > place where root could have started the LDM. When I do get LDM running > > again, I then have to clean up the problem of files created > > The LDM is setuid-root, which means that its user-ID will be "root" on > startup. It immediately sets this to the "ldm" user-ID, however, and > only uses the root user-ID when absolutely necessary (as when obtaining > a restricted port number, for example). For the overwhelming majority > of the time, the user-ID of the LDM should be "ldm". > > Is it possible that your LDM is booted at reboot time? If so, and > something goes wrong, then you might get LDMs whose user-ID is "root". LDM is booted at boot time, but this always seems to lead to ldm processes owned by ldm. I also haven't rebooted for several weeks. I think the problem was made worse by UIUC being down for two hours and a backlog of IDD traffic, etc. > > > Secondly, over the past 24 hours, I have also had LDM die (no > > processes). I use ldmfail, but that hasn't always seemed to correct the > > problem. > > I'm afraid I don't have anything to say about this. > > > The final problem is that the normally reliable "ldmadmin stop" command > > does not always seem to be stopping ldm processes, such as, pqing, > > pqexpire, pqinstats, etc.(all owned by ldm), although it was stopping > > the rpc.ldmd processes. Before I noticed this, I had restarted and > > stopped the ldm a few times for some pqact.conf changes and then > > detected several pqing, pqexpire, pqinstats, entries. > > I've been working on the LDM just recently. One of the changes I've > made has been to the "ldmadmin stop" command. The change will be in the > next release. I beseech you to hang-on until then. > > Regards, > Steve Emmerson <http://www.unidata.ucar.edu> -- James P. Koermer E-Mail: koermer@xxxxxxxxxxxxxxxxx Professor of Meteorology Office Phone: (603)535-2574 Natural Science Department Office Fax: (603)535-2723 Plymouth State College WWW: http://vortex.plymouth.edu/ Plymouth, NH 03264
ldm-users archives: