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.
Here's a followup of the pqsurf problem, for the email archives >To: address@hidden >cc: address@hidden >From: David Knight <address@hidden> >Subject: pqsurf in ldm5.1.2 >Organization: UCAR/Unidata >Keywords: 200010021701.e92H1Ub04645 ------- Forwarded Message Date: Mon, 02 Oct 2000 19:24:28 +0000 From: David Knight <address@hidden> To: address@hidden, address@hidden cc: address@hidden, address@hidden Subject: Re: 20001002: pqsurf in ldm5.1.2 Hi Russ, Thanks for the follow up. I *think* I have it resolved now (time will tell...) It has been so long since I compiled the ldm that I had forgotten about the gdbm problem. I recompiled and linked ldm-5.1.2 against the old gdbm libraries and this seems to have pqsurf working again. It will be nice to not have to run pqexpire! Later, David > > Hi David, > > > I'm finally getting around to installing ldm5.1.2 > > > > Everything seems to have gone OK, but, I can't seem > > to keep pqsurf running. After the ldm has been up for about a minute > > I get en entry like the following in the ldmd.log, > > and pqsurf dies and never comes back. > > > > Oct 02 16:32:59 redwood pqsurf[15481]: child 15488 terminated by signal 10 > > Oct 02 16:32:59 redwood pqsurf[15481]: Exiting > > Oct 02 16:32:59 redwood pqsurf[15481]: Queue usage (bytes): 60704 > > Oct 02 16:32:59 redwood pqsurf[15481]: (nregions): 371 > > Oct 02 16:32:59 redwood pqsurf[15481]: Number of products 89 > > Oct 02 16:32:59 redwood pqsurf[15481]: Number of observations 385 > > Oct 02 16:32:59 redwood pqsurf[15481]: Number of dups 7 > > > > I can start it up again manually with extra logging > > > > pqsurf -xv -l - -d /data1 -q /ldmpq/ldm.pq -Q /ldmpq/pqsurf.pq > > > > Again, it runs for a time, then stops by signal 10 > > Here is the closest I can see to an error message in the > > more verbose logs > > > > surf: End of Queue > > to 20001002155703.503 > > skip a6818ced261609cc1d3dd98c57b1e98b 104 20001002160439.236 > > IDS|DDPLUS 58001 metar PAGA 021600 RRC > > max_latency 3158.941 > > diff 3614.674 > > heuristic depth break > > > > > > I recreated all product queues when I switched > > from using 5.0.8 to 5.1.2 > > > > I'm running Solaris 2.6 > > > > Any ideas, or debugging suggestions? > > I haven't seen this before, though we don't regularly run pqsurf here. > We tested it and didn't see any problems however, and others are using > it successfully with 5.1.2. > > After pqsurf crashes, I think you should explicitly recreate pqsurf.pq > again, because it's always possible this queue was left in an > inconsistent state since it was never closed. > > When you create pqsurf.pq with pqcreate (or ldmadmin mksurfqueue?), > you may need to explicitly tell it to create more product slots (-S > numprods) in the pqsurf queue, since the computation for the number of > product slots has changed to now use a presumed average product size > of 4096 instead of the previous 2048. Both of these may be too big > for the text products pqsurf is dealing with. You can see how many > product slots have been allocated in pqsurf.pq and whether it ran out > by using > > pqmon -q /ldmpq/pqsurf.pq > > and look under the columns labeled > > nprods: current number of products > nfree: number of free (allocated but unused) product slots > nempty: number of empty (unallocated) product slots > > You can also run pqsurf independently from the LDM with error messages going > to standard output to see if that reveals what is happening. It might > be useful to run pqmon in another window updating every second to see > if it shows anything unusual about what is happening in the pqsurf.pq > file. > > Good luck ... > > --Russ > ------- End of Forwarded Message