[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[GEMPAK #NTP-422184]: no data written by dc* progs
- Subject: [GEMPAK #NTP-422184]: no data written by dc* progs
- Date: Thu, 28 Jun 2012 12:06:14 -0600
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