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
gembud archives: