[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

20040120: Problems with pqsurf/pqact... how best to assist?

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.

  • Subject: 20040120: Problems with pqsurf/pqact... how best to assist?
  • Date: Tue, 20 Jan 2004 13:03:37 -0700
Steven,

>Date: Tue, 20 Jan 2004 13:26:40 -0600
>From: Steven Danz <address@hidden>
>Organization: Aviation Weather Center
>To: Steve Emmerson <address@hidden>
>Subject: Re: 20031203: Problems with pqsurf/pqact... how best to assist?
>Keywords: 200312052033.hB5KXWp2001073

The above message contained the following:

> Just a follow-up to this issue.  No, it hasn't gone away ;-)
> 
> I've added back in the change I had proposed for ldm5 in filel.c to
> increase the max number of file descriptors from fixed value of 32 to
> the result of sysconf(_SC_OPEN_MAX) minus 16 or the constant 32, which
> ever is greater. This has greatly reduced the number of core files,
> but they haven't completely gone away.  I'm wondering if there isn't
> some problem with pqact 'knowing' what is closed/open and it is trying
> to close a closed file or something.  With the increase in possible
> open files there is less 'pressure' on the file open/close part of the
> system and things appear to work better.  Its a data point.

There is a problem with the value of the MAXENTRIES macro in file
pqact/filel.c being set to 32 -- but it doesn't seem to have anything to
do with SIGINT-s and core dumps (it has to do with ensuring that a
decoded receives all its data).

> I've also added the the second variable of an independently built gdbm 
> library from the GNU web site (version 1.8.3).
> The two together 'seem' to resolve the problem, but its hard to 
> reproduce.  I'm goinjg to go back to the RH shipped
> gdbm with the increased file handles and try reading over some core 
> files, then I'll try going to 32 file handles and an
> independent gdbm to see if by itself that makes any difference.

Considering that the pqact(1) process was in a GDBM function when it
received the SIGINT, I would not be surprised if changing the GDBM
implementation entirely accounts for the observed change in behavior.

> Just thought you might be interested.

Indeed, I'm interested.  Please keep me apprised.

> Steven

Regards,
Steve Emmerson
LDM Developer