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: "David B. Bukowski" <address@hidden> >Organization: COD >Keywords: 200106202104.f5KL4N116106 Dave, >The only changes i know of between the redhat and debian upgrades from >their previous versions is the libc6 change from libc5. Could libraries >have changed? Yes. My (and other's) thinking is that the change must be in one of three subsystems: 1) the kernel 2) libc 3) inetd Regarding 3): RedHat 7.x moved from inetd to xinetd. The configuration is different, but the concept is the same. I have this gut feeling that the problem is not in inetd/xinetd, but... >cause libc6 is now glibc2. Maybe it would have been that >change over that screwed things up? any thoughts. Yes, it might have something to do with the change. A conversation yesterday with Steve Chiswell (our GEMPAK guru) revolved around the possibility of the meaning of a signal (SIGINT) being changed at some point in the past. I will be talking to him about this one again today. >well either the old mcidas box (picard) or i might be able to swipe >another dual PPro and do a quick install of linux and ldm and u can handle >the mcidas stuff we could have a box for u to totally play with and break >over here too :) Here is the story: McIDAS is working fine except for the serving of sounding data through the remote ADDE server, and even that _usually_ works OK if the client machine is on the same subnet as the server machine. Also, McIDAS can access the sounding data with _no_ problems if the RTPTSRC dataset is found either as LOCAL-DATA or gotten from a remote machine that is not running a current version of Linux. Everything else (local and remote access of all other data) seems to run fine on the latest versions of Linux. As far as the LDM goes, we have had reports from a couple of sites that they sometimes see their LDM machine go into a mode of severe disk thrashing. This appears to only happen on RedHat 7.1 (I should say that we only have maybe one or two sites running Debian, and their machines are not as loaded as the machines that are experiencing the thrashing). Have you experienced any of this on weather? I don't think so since ADDE access to your box is always very fast. If you do have a spare box "sitting around" (:-), it would be useful to run some staged tests to see exactly where things started breaking. What I have in mind is: 1) I know that RedHat 5.2 (I believe that this is the 2.0 Linux kernel) runs all McIDAS code with no problems 2) It would be _very_ useful to start off with an absolutely clean install of RedHat 6.0 (or its Debian equivalent) to see if things still worked or if it was broken. 3) If RH 6.0 was not broken, I would upgrade to 6.1 and test it, and so on. 4) I know that RH 6.2 is broken (for the remote serving of souning data, of course), so the _big_ change had to be somewhere between 5.2 and 6.2. My suspicion is that the ability to reliably serve sounding data through the remote ADDE server was lost in the libc upgrade, but I don't know exactly when this happened. If it did break then, it seems like it is most likely that the problem is related to changes in the C library. What do you think? re: use of syslog-ng >basically syslog.conf is overridden by syslog-ng.conf cause thats the >binary running now... dont really know what happened to syslogd in the >packages available. OK. This is akin to the movement from inetd to xinetd in RedHat 7.x. re: we don't know nothing about no stinking syslog-ng.conf ;-) >If I find out i'll relay the information to you guys/gals :) Thanks! >would it be alright to start up a mcidas client running off of cronjob >batches now at least so we can offload the work of one of the machines >which i could then prolly set up for u to test off of also... if i free up >computers i can start using those puters for testing. Yes, absolutely. Again, the only thing that does not run 100% correctly is the remote serving of sounding data. >I MIGHT have a copy of redhat 6.0 at home somewhere which someone made a >burn on cd for me of. Super. If you do have a spare box to load it on, and if the box can be put on the net (and properly safeguarded from hackers!!), then it would be a useful platform to find out exactly when things broke. As an aside, we never noticed the breakage at Unidata 'cause we use Suns for serving ADDE. Our experience is that Solaris x86 is a much more robust platform for the applications we support. If only Sun would keep up on new hardware like current video cards! Another aside: one of our site's experience is that FreeBSD is a much better OS than Linux. It is faster, less likely to get hacked into, has better NFS support, and has one of, if not the best TCP/IP stacks in any OS. If I could wave a magic wand, I would get more people using FreeBSD. >also have slackware on cd at home up to 4.0 3.0 and 4.0 and 3.6 i think >are the versions i have I don't know how the Slackware releases translate to the revisions of libc, etc. I think that it would be better to stick with looking at RedHat an Debian for now. >ps. if u need to get a hold of me quickly u can email page me at >address@hidden only 300 characters please else i have to tell >it to send me MORE of the message like every 250-300 characters which >takes time :) OK, thanks. I will remember this (and make sure that it does not get into the tracking system!). >So if u come across an idea u want to test out that would >work. And if u want to go conferencing somehow i'm available on icq i can >fire up and irc, aol/im, yahoo messenger... pretty much any of those. OK, sounds good. Thanks! Tom