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

Re: 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: Re: 20050322: EXEC stderr output getting into PIPE results?
  • Date: Wed, 23 Mar 2005 13:09:12 -0700
Steven,

>Date: Wed, 23 Mar 2005 13:24:53 -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:

> While the new version doesn't have problems with stomping files, the
> stderr of all EXEC and PIPE processes are being sent to /dev/null,

Not quite.  Standard error is connected to /dev/null if and only if it's
connected to something other than a file in the pqact(1) process.  This
makes sense because if standard error is connected to the syslog(8)
daemon, then it wouldn't make sense for a PIPE child process to write to
standard error.

> so diagnosing problems is +/- impossible.  In 6.3.0, if a log file
> is specified to pqact, stderrIsValid is set to 0 and nothing gets to
> write to it except for pqact.

Not quite.  The code is

    if (NULL == logfname || 0 != strcmp(logfname, "-")) {
            (void)fclose(stderr);
            stderrIsValid = 0;
    }

So, if a logfile or "-" is specified, then "stderrIsValid" will be true
by default and will not be connected to /dev/null before the decoder 
is executed.

If pqact(1) is executed via an EXEC entry in the LDM configuration-file,
then it makes no sense to specify "-" as the logfile because the
pqact(1) process doesn't have a controlling terminal in that situation.

> I don't guess there is a middle ground where the openulog() could
> be smart enough to put the pqact's log on stderr and reassign the
> stderrIsValid to 1?

Specifying a regular file as the logfile should work.

If the above isn't true, then I need to know ASAP.

Regards,
Steve Emmerson