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.
Paul, > I am working on the LDM for RAL at NCAR. We have several questions that we > hope > you can help with. > > 1) We were trying to capture the results of 'ldmadmin watch' and make it > available on our internal webserver, so that our downstream clients can > see exactly what we is passing through our 'gateway' ldm. We are using > 'pqutil -r -w /home/ldm/data/ldm.pq' to do this, but notice that it > often shows 90%+ cput utilization (via top). Do you have any recommendations > for a more efficient way to capture this information? The pqutil(1) utility is, actually, an interactive program: it's designed to expect user-supplied input; consequently, it can consume a lot of CPU when used in a non-interactive setting. I suggest using the notifyme(1) utility, instead. > 2) We have noticed that sometimes we end up with log files owned by root, > and also some log files that are zipped, or have a .0 extension. As far as > I know we always run the ldm under the ldm user (although we are using > a script /etc/init.d/ldm to automatically start the ldm when the machines > boot up). Do you have any suggestions for how root is becoming the owner > of these logs? I would check the boot-time start-up script for the LDM to ensure that the root user is becoming the LDM user before executing the "ldmadmin start" command. For security reasons which I don't understand, our system > admins, do not like to have hupsyslog in ~ldm/bin. Instead hupsyslog in > ~ldm/bin is a symbolic link to /opt/bin/hupsyslog. The link is owned > by ldm, but /opt/bin/hupsyslog is owned by root with an ldm group. > Could this be the problem? The hupsyslog(1) utlity only sends a SIGHUP to the syslog(8) daemon: it doesn't do anything with the LDM log files; consequently, it can't be responsible for root owning those files. > 2b) We've noticed that pqact & pqsurf logs don't seem to rotate correctly. > When we run ldmadmin newlog a new log is created, and the numbers rotate, > but the now the .1 file is being written to. The new log file just stays > at zero size. Is this just the manner in which pqact/pqsurf work (i.e. > not releasing their file handle each time they write), or is there something > we are doing wrong? The pqact(1) and pqsurf(1) programs are started by EXEC entries in the LDM configuration-file. I suspect that those entries are explicitly specifying what log file to use -- via the "-l" option -- instead of using the default (logging to the LDM log file). If so, then just remove the use of that option from the EXEC entries. > 3) Did you do any load testing on your LDM cluster? We would like to > do some testing before we make ours available to the rest of RAL. We > remembered > the Unidata classroom, and were wondering if it would be possible to configure > those machines to all try to request everything from our LDM cluster, to > see what our load looks like under those conditions. Intriguing idea! I'll let you know. > Thanks, > Paul & Gary Regards, Steve Emmerson Ticket Details =================== Ticket ID: BLL-845073 Department: Support LDM Priority: Normal Status: Closed