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: Nancy Selover <address@hidden> >Organization: ASU >Keywords: 200507190034.j6J0Ywjo000855 LDM install Nancy, re: ldmadmin can't be found >We had the links wrong, but have fixed them. OK. >I double checked all the >config files to be sure I had properly edited everything, but I am >getting the start-up error: > >Sh: /etc/killall: No such file or directory >Hupsyslog: system( "/etc/killall -HUP syslogd") returns 32512 >(E.G. It didn't work. Check that this program is setuid) > >How do I check that - what do I do? This is very strange since hupsyslog will try to run /etc/killall on SGI systems only. On Linux, it should: - get the syslogd PID from the file /var/run/syslogd.pid - run (as 'root) 'kill -HUP syslogpid The fact that your build is trying to run /etc/killall suggests that there were some enviornment variable definitions in place that were appropriate for an SGI installation when 'configure' was run on your Fedora Core 3 machine. Is it possible that you defined some environment variables on your FC3 machine based on experience on an SGI machine? If yes, please remove those definitions and rebuild your LDM distribution from scratch: <as 'ldm'> cd ~ldm -- edit shell definition file and remove the environment variables that were defined logoff login (this is the easiest way to make sure the definitions are gone) cd ~ldm/ldm-6.3.0/src make distclean ./configure make make install sudo make install_setuids If inappropriately defined environment variables is not causing your problem, please send us the contents of ~ldm/ldm-6.3.0/src/config.log and ~ldm/ldm-6.3.0/src/macros.make. Cheers, Tom -- 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.