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: Gilbert Sebenste <address@hidden> >Organization: NIU >Keywords: 200511022216.jA2MGA7s022056 LDM Fedora Core 3/4 syslogd Hi Gilbert, >I am about to upgrade weather3.admin.niu.edu from Fedora Core 1 to Fedora >Core 4 on Monday. Sounds good. >You warned me if I did this, to contact you ahead of >time because there are several "gotchas" I need to watch out for, >including, if I recall correctly, logging of LDM logs. Yup. In order for you to keep using syslogd for LDM logging ** at the current time ** you will need to disable SELINUX. This is done by editing the file /etc/selinux/config and: change: SELINUX=enforcing to: SELINUX=disabled and then rebooting. We are working to understand Selinux better so that we can come up with needed entries for syslogd.te so that the LDM can keep use syslogd for logging. Currently, if SELINUX is set to enforcing in /etc/selinux/config, a user process is prevented from using syslogd for logging. >What else do I need >to watch for, and how can I help get it right the first time? I have also noticed that as machines get faster and the versions of Linux get newer, folks have been having more and more problems building McIDAS-X. The cause for the problem is apparently something in the OS where memory cached information is not being written out to disk. Explicitly what happens is that object modules that are correctly created by the C (gcc) or Fortran (g77) compilers do not get added to one or both McIDAS libraries libmcidas.a and libsdi.a. The result of this failure to add the entry point the library is that a link will fail at some point further in the make process. The procedure I have found to work is to look at the end of the make log file (makelog) to see what object module(s) were not found in which library and then manually add it/them and continue with the build. My most recent brush with exactly this situation was on a FreeBSD 5.4 machine where the object module nexrutil.o was not added to libmcidas.a. In that case, it was the only object module not added to the library. The manual sequence in this case was: <as 'mcidas' doing a build in the ~mcidas/mcidas2005/src directory> less makelog ar r libmcidas.a nexrutil.o ranlib libmcidas.a make Just so you know, this failure is not dependent on the version of McIDAS being built -- it occurs for all versions. Also, just so you know, I run Fedora Core 4 on a 700 Mhz PIII machine at home (i.e., a slow machine), and I have NEVER experienced a problem with object modules not being added to a library. I have only seen the problem on newer, _faster_ machines. That is all I can remember at the momment. 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.