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: Mark Seefeldt <address@hidden> >Organization: CU >Keywords: 200511110014.jAB0EW7s019600 LDM hupsyslog syslogd Hi Mark, >I have recently upgraded to LDM 6.4.3 >When starting up the LDM I receive the following error: > hupsyslog: couldn't open /var/run/syslogd.pid This seems to indicate you are running on a Linux system. Please let me know if this is not the case. >When searching the email archive I came across a similar problem and the >solution was to remember to execute: > make install_setuids This is the typical problem, yes. >I did execute this make command, but not as root, as myself using sudo >permissions. Running the command with a sudo should be equivalent to being root and running it: sudo make install_setuids >I would think with sudo it would behave as root, but I am >not certain. It should, yes. >Is there anyway to verify if the necessary changes were done? Yes. Please do the following: <as 'ldm'> cd ~/bin <- assumes that you made the recommended runtime link ls -alt rpc.ldmd hupsyslog The listing should show that both processes have setuid permission. On my Linux system this looks like: -rwsr-xr-x 1 root ustaff 646980 Oct 14 13:22 rpc.ldmd -rwsr-xr-x 1 root ustaff 10524 Oct 14 13:22 hupsyslog Note the 's' flag and the indicated owner. If your 'hupsyslog' and 'rpc.ldmd' processes look like this, then the problem is most likely that the syslogd PID is not there. Check this with: ls -alt /var/run/syslogd.pid If the file is not there, syslogd is not running. Check this with: ps -eaf | grep syslogd If syslogd is not running, you can restart it (as 'root' and assuming you are on a Linux machine) using: <as 'root'> /etc/init.d/syslogd start >Thank You Please let me know if the above solves your problem. Cheers, Tom Yoksas -- NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us. >From address@hidden Fri Nov 11 12:02:07 2005 Tom, re: your OS >Yes, I am on a Linux system. Sorry about forgetting this detail. re: long listing for hupsyslog and rpc.ldmd >My listing: >[ldm@foehn bin]$ ls -lta rpc.ldmd hupsyslog >-rwxr-xr-x 1 ldm met-apps 187145 Nov 10 14:19 rpc.ldmd >-rwxr-xr-x 1 ldm met-apps 5579 Nov 10 14:19 hupsyslog >I changed the owner to root using sudo chown. >I changed the x to an s for the user using sudo chmod. >I then had the following listing: >[ldm@foehn bin]$ ls -lta rpc.ldmd hupsyslog >-rwsr-xr-x 1 root met-apps 187145 Nov 10 14:19 rpc.ldmd >-rwsr-xr-x 1 root met-apps 5579 Nov 10 14:19 hupsyslog re: does the syslogd.pid file exist >The syslogd.pid file was missing, but that was a part of my attempts to >fix the problem yesterday. The syslog was partially running. I shut >down syslog completely, and then started it up. >After completing all of the above, I then stop ldm, and then started it >up. I no longer received the error. >[ldm@foehn ~]$ ldmadmin stop >Flushing the LDM product-queue to disk... >Stopping the LDM server... >[ldm@foehn ~]$ ldmadmin start >The product-queue is OK. >/usr/local/ldm/etc/pqact.conf is syntactically correct >Starting the LDM server... >Thank you for your assistance. >Mark