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

20050322: EXEC stderr output getting into PIPE results?

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.

  • Subject: 20050322: EXEC stderr output getting into PIPE results?
  • Date: Wed, 23 Mar 2005 10:45:55 -0700
Steven,

>Date: Tue, 22 Mar 2005 16:35:45 -0600
>From: "Steven Danz" <address@hidden>
>Organization: Aviation Weather Center
>To: Steve Emmerson <address@hidden>
>Subject: [Fwd: Re: 20050322: EXEC stderr output getting into PIPE results?]

The above message contained the following:

> Ok, well I -think- I found the problem in 6.2.1.  I don't have 6.1.x to 
> compare with handy
> but I think it was there as well.  In pqact.c, stdin, stdout, and if a 
> file name is given, stderr
> are all closed up front, with the expectation that the descriptors will 
> be used later for logging,
> the product queue, and the configuration file.  The situation ends up 
> like this:
> 
> 1) the first thing opened is the log file, so it gets file descriptor 0
> 2) the next is the queue, on descriptor 1
> 3) the last is the config file, on descriptor 2, which then is closed so 
> descriptor 2 is
>    available for use later by pqact!
> 
> When a EXEC or PIPE is started, then the child of the fork() expects to use
> file descriptor 2 for stderr, but given that we closed it, and didn't 
> force the pqact
> log file to it, it gets whatever pqact has assigned to it at the time.  
> Which could be
> a file or pipe to anywhere.  In the 6.0.14 days, stdin and stderr were 
> not closed
> and stderr was only closed -just- before the log was opened so the log 
> ended up
> on descriptor 2.
> 
> Or am I way off base?

I'm not sure.  I"d have to examine the code to be certain and there are
more pressing matters to which I must attend.

If you encounter a problem with the new version, however, then please 
let me know.

Regards,
Steve Emmerson