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

Re: 20050322: EXEC stderr output getting into PIPE results?

Steven,

>Date: Wed, 25 Jan 2006 13:24:08 -0600
>From: Steven Danz <address@hidden>
>Organization: Aviation Weather Center
>To: Steve Emmerson <address@hidden>
>Subject: Re: 20050322: EXEC stderr output getting into PIPE results?

The above message contained the following:

> Hi! I've been out of the LDM game for awhile, and am trying to catch up 
> to the latest version and I wanted to follow up on this issue.
> I'm reading the change log, and in 6.4.2 it mentions:
> 
>         pqact(1):
> 
>             Fixed bug described in
> 
>                 
> http://www.unidata.ucar.edu/cgi-bin/getfile?file=/content/support/help/MailArchives/ldm/msg04238
> 
>             by improving how pqact(1) manages its file descriptors.
>             File descriptors are now reserved for stdin, stdout,
>             stderr, the configuration-file, the product-queue, and
>             (possibly) logging.  Stdin and stdout are redirected to
>             /dev/null at startup to prevent problems with miscoded child
>             programs.  Stderr is redirected to /dev/null if logging
>             isn't to stderr.  Most other file descriptors are set to
>             close-on-exec.
> 
> And I'm confused.  It now looks like none of the children of pqact can 
> access stderr anymore???  So if a decoder crashes or script has a syntax 
> error or the like, the stderr output just gets lost?  This seems to be a 
> huge step backwards in the 'maintainability' of things as many times 
> this is the only clue as to what is going on and what caused the 
> problem.  Before, the stderr of the children went to where ever pqact 
> was sending log info, be that file, stderr or syslog.

Child processes of pqact(1) could never depend on writing to the
standard error stream because, normally, that stream is a connection to
the syslog(8) daemon, which requires that log messages be in a certain
format.  Consequently, arbitrary log messages from decoders would,
normally, be lost.

The solution to logging by decoders has always been that they must use
the system logging utility, logger(1), or build and install the LDM
logging utility, ulogger(1).

> Or am I missing something?  I've tried testing this with a 4 line perl 
> script that just prints all stdin to stderr, and it seems that its all 
> going into the bit bucket...      From what I remember, the only way to 
> get this to work right before was to fclose(stderr) right before 
> openulog() (if the logfile wasn't '-' or was null) so that the stderr 
> file descriptor would be reused when the log file descriptor is 
> created.  Maybe a command line option to allow child procs of pqact to 
> write to stderr could work?
> 
> Thanks for your time!  (Is gforge gone for good or just out for 
> maintenance?  I was going to put this there but couldn't access it)

The network administrators here seem to prefer that it be gone for
good.  :-(

Regards,
Steve Emmerson