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

[GEMPAK #NTP-422184]: no data written by dc* progs

Ah, good to know.





> Mike...
> 
> I found a fix to the problem.  Here's what I posted on gembud:
> 
> 
> 
> FOR THE RECORD:  Fixed!
> 
> I have no idea why this worked.  I re-generated my LDM pqact.* files from the
> gen_pqact.csh script instead of the gen_pqact_GEMDATA.csh script.  For 
> whatever
> reason, the dc* decoders like to dump the decoded .gem files into the
> $LDMHOME/data symlink.  I just created another sym link inside $LDMHOME/data
> and pointed it to where I wanted the data to go, and now all is well.
> 
> HUGE THANKS  to Michael James for taking the time to look into this for me!
> 
> -Mike-
> 
> 
> Hopefully others could benefit.
> Thanks for the help!
> 
> -Mike-
> 
> -----Original Message-----
> From: Unidata GEMPAK Support [mailto:address@hidden]
> Sent: Thursday, June 28, 2012 10:37 AM
> To: Van Tress,Michael J (BPA) - PGPW-5
> Cc: address@hidden
> Subject: [GEMPAK #NTP-422184]: no data written by dc* progs
> 
> Some things to check:
> 
> - Is ~ldm/data/ full or near full? The unix command 'df' will show filesystem 
> usage. If it's near-full then you may be out of disk space and you'll have to 
> modify the scouring of old data files.
> 
> - Verify the read/write/execute permissions on ~ldm/data/gempak/
> 
> - Are there two instances of any one decoder running concurrently?  If so 
> both instances may be trying to write to the same file.  If you see multiple 
> process IDs in the decoder log at approximately the same time this would 
> indicate multiple instances of a decoder and we'll have to find the duplicate 
> pattern action in your pqact files.
> 
> 
> Michael James
> Unidata
> 
> 
> > I've noticed from the past posts that this has been a problem, but I don't 
> > see a post with a solution.
> > Is there a soltuion?  I'd be very greateful if someone would share if there 
> > is.
> >
> > I've disabled ipv6 on our system.
> >
> > Here's a previous description that fits mine to the tee:
> >
> >
> > I've run into a problem with 5.11.4 where the decoders will not write files 
> > into $GEMDATA. If I wipe out the directory structure, the progs will create 
> > all of the proper subdirectories, but they will not be populated with data. 
> > In the various log files, all the apps complain about not being able to 
> > write to files. I've double checked the write permissions on the 
> > directories and ldm has write permissions (gempak was built under the ldm 
> > account, no gempak user.)
> > My system is:  Redhat Enterprise 4
> > Kernel is:   2.6.9-89.ELsmp #1 SMP Mon Apr 20 10:34:33 EDT 2009 i686 i686 
> > i386 GNU/Linux
> > There were no errors in the make or make_install logs that I could tell.
> >
> >
> >
> >
> 
> Ticket Details
> ===================
> Ticket ID: NTP-422184
> Department: Support GEMPAK
> Priority: Normal
> Status: Open
> 
> 


Ticket Details
===================
Ticket ID: NTP-422184
Department: Support GEMPAK
Priority: Normal
Status: Open