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.
>From: "David Delgado" <address@hidden> >Organization: University of Wisconsin-Whitewater >Keywords: 200001241716.KAA06989 LDM David, >There are several issues that I must ask about LDM. This may be a very >rudamentary question but a question none-the-less. > >First issue >----------- > >When I log in as LDM (ownership ldm.unidata) and type > > $ ldmadmin start > >I get the following message: > > starting the LDM server... > hupsyslog: kill -HUP 263: Permission denied > the LDM server has been started This is most likely telling us that the routine hupsyslog does not have the SUID bit set, meaning that it does not run as 'root'. What hupsyslog does is send a HUP signal to the syslogd process so that the LDM log files can be rotated. Since only 'root' can do this, hupsyslog has to have the appropriate permissions set _by root_ during an LDM installation. This is discussed in: Unidata Homepage: http://www.unidata.ucar.edu LDM http://www.unidata.ucar.edu/packages/ldm LDM Binary Installation Check List http://www.unidata.ucar.edu/packages/ldm/ldmBinaryInstallList.html Make rpc.ldmd and hupsyslog suid root or LDM Source Installation Check List http://www.unidata.ucar.edu/packages/ldm/ldmSourceInstallList.html Compile the distribution >So, the service is starting (I can watch data come in using "ldmadmin >watch") but logging isn't working. If no logging is working, then you may be having a problem with syslogd. If hupsyslog does have SUID capability, then you should kill syslogd as 'root' and start another invocation. >Can you provide a hint on where to find where permissions are wrong? See above. >Second issue >------------ >I understand the importance of understanding the documentation of >pqact.conf. We've needed to adjust settings times in the past. For the time >being, is there a default pqact.conf file that we can use to receive all of >the usual data products? I can make the one we use available to you, but given how configurable ingestion is, you might have to do a lot of work on it. >Just so you know...I attempted the upgrade of the OS and was successful. I >was also semi-successful in upgrading McIDAS and LDM on mcidas.uww.edu. Semi-successful? What exactly did not go well? >Unfortuantely, that did not cahnge our situation at all. The same errors >from before the upgrade were evidant after the upgrade and a step backwards >was taken. Instead of sending inconsistant data for no more than 24 hours we >weren't sending data to our workstation at all. So, you are using one machine to relay data to another? I searched our tracking system under LDM and IDD and see that the last inquiry from you was in November. Are these the problems you are referring to? >Thanks in advance. Please let me know exactly what problems you are having so we can get you running correctly. Tom Yoksas