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.
I spoke too soon. The DCGRIB -11 errors are occurring again and I'm looking at it now. -Michael > Thanks! > > Douglas > > On 8/19/13 4:55 PM, Unidata GEMPAK Support wrote: > > From the /var/adm/messages line > > > > Aug 19 18:03:14 unidata2-new.ssec.wisc.edu genunix: [ID 603404 kern.notice] > > NOTICE: core_log: dcgrib2[20848] core dumped: > > /data/core/core.dcgrib2.20848.u8858 > > > > I trace process ID 20848 to the following entries in ~ldm/logs/ldmd.log > > > > Aug 19 18:03:14 unidata2-new.ssec.wisc.edu pqact[18665] ERROR: pipe_put(): > > write error: pid=20848, cmd=(decoders/dcgrib2 -v 1 -d > > data/gempak/logs/dcgrib2_fnmoc.log -e > > GEMTBL=/home/gempak/NAWIPS/gempak/tables) > > Aug 19 18:03:14 unidata2-new.ssec.wisc.edu pqact[18665] ERROR: Deleting > > failed PIPE entry: pid=20848, cmd="decoders/dcgrib2 -v 1 -d > > data/gempak/logs/dcgrib2_fnmoc.log -e > > GEMTBL=/home/gempak/NAWIPS/gempak/tables" [filel.c:288] > > Aug 19 18:03:14 unidata2-new.ssec.wisc.edu pqact[18665] WARN: child 20848 > > terminated by signal 11 > > > > and in ~ldm/data/gempak/logs/ I see the dcgrib2_fnmoc.log file was over 2 > > GB in size! I created a new logfile for the fnmoc feed and so far have not > > see any further DCGRIB -11 errors in the new log. I think this problem was > > caused by not rotating the GEMPAK grib decoder logs. > > > > -Michael James > > Unidata > > > > > > > > > > > >> Hi Tom > >> > >> Thanks for all the information. I'll make some notes. > >> > >> Be well. > >> > >> Douglas > >> > >> On 8/19/13 12:26 PM, Unidata GEMPAK Support wrote: > >>> Hi Douglas, > >>> > >>> re: > >>>> We are seeing a lot of core dump messages this morning on unidata2-new > >>>> for dcgrib2 procs. > >>> OK, thanks for letting us know. Since 'dcgrib2' is a GEMPAK decoder, I > >>> will pass the information along to our GEMPAK person. > >>> > >>> re: > >>>> I thought I might try to restart xcd via xcdadmin but I do not know how > >>>> xcd is started on unidata2-new. > >>> Why did you want to restart XCD? Perhaps you thought that 'dcgrib2' is > >>> not a McIDAS XCD routine? > >>> > >>> re: > >>> It appears to be running under ldm but > >>>> the config file shows oper as the admin user: > >>>> > >>>> xcd_admin="oper" > >>>> xcd_admin_home="/home/oper" > >>>> xcd_admin_profile="$xcd_admin_home/.profile" > >>>> > >>>> It does not look like the file was updated recently. > >>>> > >>>> Here is a sample of the error messages we are seeing in > >>>> /var/adm/messages: > >>>> > >>>> Aug 19 16:52:30 unidata2-new.ssec.wisc.edu genunix: [ID 603404 > >>>> kern.notice] NOTICE: core_log: dcgrib2[6390] core dumped: > >>>> /data/core/core.dcgrib2.6390.u8858 > >>>> Aug 19 16:52:36 unidata2-new.ssec.wisc.edu genunix: [ID 603404 > >>>> kern.notice] NOTICE: core_log: dcgrib2[6656] core dumped: > >>>> /data/core/core.dcgrib2.6656.u8858 > >>>> > >>>> The error state has existed for almost 4 hours as I type this. > >>> The McIDAS-XCD decoders running on unidata2-new are from the Unidata > >>> McIDAS-X/XCD distribution. This installation eliminates the use of > >>> an 'oper' account; the running of the XCD data monitors and decoding > >>> processes is handled in the 'ldm' account, and the configuration of > >>> the XCD data monitors, etc. is handled in the 'mcidas' account. I > >>> eliminated the 'oper' part of McIDAS installations in the Unidata > >>> McIDAS-X/XCD release as soon as XCD was allowed (by Bob Fox and > >>> then Tom Achtor) to be bundled with Unidata McIDAS. This was over > >>> 12 years ago (I think). > >>> > >>> Anyway, the problem is with a GEMPAK decoder run from an 'ldm' > >>> pattern-action file. I will let our GEMPAK guy know that the > >>> installation on the machine needs attending to. > >>> > >>> re: > >>>> Thanks in advance. > >>> Sorry for the confusion... > >>> > >>> Cheers, > >>> > >>> Tom > >>> -- > >>> **************************************************************************** > >>> Unidata User Support UCAR Unidata > >>> Program > >>> (303) 497-8642 P.O. Box > >>> 3000 > >>> address@hidden Boulder, CO 80307 > >>> ---------------------------------------------------------------------------- > >>> Unidata HomePage http://www.unidata.ucar.edu > >>> **************************************************************************** > >>> > >>> > >>> Ticket Details > >>> =================== > >>> Ticket ID: OKF-212399 > >>> Department: Support GEMPAK > >>> Priority: Normal > >>> Status: Open > >>> > >> > >> -- > >> > >> SSEC Data Center Email:address@hidden > >> UW Madison Web:http://www.ssec.wisc.edu/datacenter > >> 1225 W. Dayton Phone: (608) 262-0502 > >> Madison, Wisconsin 53706 Fax: (608) 263-6738 > >> > >> > > Ticket Details > > =================== > > Ticket ID: OKF-212399 > > Department: Support GEMPAK > > Priority: Normal > > Status: Open > > > > > -- > > SSEC Data Center Email:address@hidden > UW Madison Web:http://www.ssec.wisc.edu/datacenter > 1225 W. Dayton Phone: (608) 262-0502 > Madison, Wisconsin 53706 Fax: (608) 263-6738 > > Ticket Details =================== Ticket ID: OKF-212399 Department: Support GEMPAK Priority: Normal Status: Open