Re: [gembud] dctaf running amok

Gembuds:

This is being caused by a mis-coded remark section from one station. The
decoder is getting into an infinite loop. I had hoped to get a release out
before this became a big issue. In the meantime, here is a fixed file that
goes in $GEMPAK/source/bridge/tf/. It now looks for a remark that starts
with either "RMK" or "BY".

Scott



On Thu, Feb 20, 2014 at 9:11 AM, Stonie R. Cooper
<stonewall@xxxxxxxxxxxxx>wrote:

> Devin - yes; I had some luck refining the pqact.conf to FTUS instead of
> just FT . . . but even then, every once in a while, dctaf goes amok.
>
> The end solution was to add a -close after the PIPE, add a -t 1, then
> have a periodic cron that watches for dctaf processes more than a minute
> or so old, then kill them.
>
> Stonie
>
> On 02/20/2014 08:03 AM, Devin Eyre wrote:
> > For the last week or so, every morning when I've checked our ldm server,
> there's been two or three dctaf processes running, with two of them using
> up 100% of a CPU core, and more than an hour of actual CPU time on each
> one.  We're running GEMPAK 6.6.0.  Has anyone else seen this happen, or
> found a way to prevent it from happening?
> >
> >
> > Devin Eyre
> > Lead Software Developer
> >
> > ImpactWeather, Inc.
> > A STORMGEO COMPANY
> >
> > Direct +1 (281) 652-1073
> > Toll-Free (877) 792-3220
> > E-mail devin@xxxxxxxxxxxxxxxxx
> > Web impactweather.com
> > _______________________________________________
> > gembud mailing list
> > gembud@xxxxxxxxxxxxxxxx
> > For list information or to unsubscribe,  visit:
> http://www.unidata.ucar.edu/mailing_lists/
> >
>
> _______________________________________________
> gembud mailing list
> gembud@xxxxxxxxxxxxxxxx
> For list information or to unsubscribe,  visit:
> http://www.unidata.ucar.edu/mailing_lists/
>

Attachment: tfdecd.f
Description: Binary data