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.
Scott, > [ldm@fetch1 ~]$ grep local /etc/syslog.conf > local7.* /var/log/boot.log > local3.debug /usr/local/ldm/logs/ldmd.log The "local3.debug" entry looks correct. The file /etc/syslog.conf should, however, also have the "none" entries for "local3" that are mentioned in the instructions. Otherwise, LDM log messages will also be written to the system log file. > [ldm@fetch1 ~]$ > [ldm@fetch1 ~]$ ls -l $HOME/ldm-6.4.6/bin/hupsyslog > -rwxr-xr-x 1 ldm users 5579 Oct 23 19:35 > /usr/local/ldm/ldm-6.4.6/bin/hupsyslog The protections on the installed hupsyslog(1) utility indicate that it won't be able to send a SIGHUP to the syslogd(8) processes -- causing it to reread its configuration-file. Did the reinstallation of the LDM 6.4.6 set the ownership of the rpc.ldm and hupsyslog programs to "root" and are they now setuid? > Not sure why, but my downstream servers are connecting to it now.. Your > procedure is exactly what I have written down, so I'm not sure why it didn't > work the first time. > > Moot point now, my 6.x.x downstream servers are fine.. However, I am getting > this error on occasion on my 5.0.8 server.. About 1 out of every 10 products.. > > Oct 25 21:50:16 arhdata fetch1(feed)[15227]: > ATTCAM_vrh_Kashevarof.1025_215000.jpg: RPC_CANT_RECV (4) > Oct 25 21:50:16 arhdata fetch1(feed)[15227]: Exiting Odd error. Is there any corresponding message from fetch1's LDM? Regards, Steve Emmerson Ticket Details =================== Ticket ID: SVU-966060 Department: Support LDM Priority: Normal Status: On Hold