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: Unidata Mcidas Account <address@hidden> >Organization: UPRM >Keywords: 200108221940.f7MJef108307 LDM pqact Linux kernel upgrade Luis, >Hi, yesterday I installed the latest Linux kernel on our machine. >After I restarted it seems that LDM is not receiving the latest images. I >checked /var/data/ldm/log/ldmd.log and I got the following error message: > >mcidas@atmos:/var/data/ldm/logs$ tail -f ldmd.log >Aug 22 19:43:10 atmos pqact[203]: child 30168 exited with status 127 >Aug 22 19:43:10 atmos pqact[203]: child 30170 exited with status 127 >Aug 22 19:43:10 atmos pqact[203]: child 30172 exited with status 127 >*snip* > >What's the problem? This is telling us that pqact is exiting prematurely for some reason. My first guess would be that shared libraries needed by pqact are either no longer available, or are in a different location. The first thing to try is: <login as 'ldm'> cd bin ldd pqact This will show you the list of shared libraries that pqact needs and finds to run. If one is needed but not found, the listing will tell indicate this. >Is it a damaged queue? Probably not, but it depends on how you shut down the system before doing the upgrade. For instance, if you threw the new kernel in and then did a quick reboot _without shutting down the LDM_, you may have damaged the queue. >I wanted to ask and be sure >before deleting/remaking the ldm queue. It was prudent to ask. >It seems that the pqact child >processes have no new information to work with. They are certainly exiting with a bad status. The fact that they are being run, however, indicates that there is something in the queue. >Do you need more information? If you did a quick reboot, you may have damaged the queue. In this case, go ahead and delete the queue and remake it. This will cause the entire last hour's worth of data to be sent from your upstream host(s), but it will be the quickest way of seeing if things improve. On a different topic, I attended the AMPATH workshop held in Miami, FL last week. During the workshop, we were told that Puerto Rico just got connected to high speed fiber cable. Figuring that UPRM's connectivity may improve because of this network upgrade, I tried doing some IMGDISPs from atmos.uprm.edu back to my home machine. The connectivity seemed the same as before the supposed new fast connection. Can you shed any light on what may be going on networkwise in Puerto Rico? If you can't, perhaps Roy Armstrong could (he was at the workshop also). >Thanks, Please let me know the results of deleting and remaking the queue. Tom >From address@hidden Wed Aug 22 17:46:09 2001 >Subject: Re: 20010822: LDM error after Linux kernel upgrade Tom, Deleted the queue, remade and it worked fine. I thought it did an ldmadmin stop when it when on runlevel 6, I'll add that later today. re: UPRM networking I don't think that upgrade will change much with the university's connection. The problem is not the island's connectivity, it's with the university. Here's our problem: The university's main campus is in San Juan, all the other campuses connect to San Juan(about 12 total). In our specific case, UPRM is connected to san juan using a T1(1.45Mbit, right?) line(yeah, just one). Actually, there are about 20 of those, but all but two are used for telephony, the other one is a backup inernet line. Ok, this line is rented from a local wireless telecom company(Cingular, which used to be Cellular One). It just plain sucks. All the other campuses connect to San Juan also, there, the university has the main line to the inernet. This line, if I'm not mistaken is a T3(45Mbits), but I'm not sure, it could be a partial line. Anyway, there's a HUGE bottleneck in San Juan, and the university does nothing about it. I happen to know a couple of people in charge of the inernet connection locally. They're working on an internet 2 line which will connect the campuses via ATM at OC-12 speed(I could be wrong about that) and they also plan to add two extra T1's just for our campus. The internet 2 line is supposedly finished already(not really sure) and the two T1's is just something I heard a couple of months ago, may or may not be true. Going back to the beginning of the email, the problem is not with the island's connectivity. I know a several people who have DSL and have a fairly good internet connection. Two weeks ago I got a cable modem, just to give you an example, downloads are anywhare from 50KB/s to 400KB/s. The fastet I've gotten from the university's connection is about 150KB/s. That was at night while I was working on a project, and I was downloading something from sunsite.unc.edu. I've got a better inernet connection home than than the university(at least our campus). It used to be worse, it got a lot better when they started filtering traffic. (Napster/Gnutella/etc). I was just speaking with Amos(my boss at the climate center) today and we were discussing alternate internet access just for the climate center. He was leaning towards sattelite access, althought I've heard only bad things about it. Another option is reaching an agreement with the cable company so we can connect throught them. We'll have to see if we can work something out. Hope this clears up any doubts. Luis Munoz System Administrator Caribbean Climate Center @ UPRM