Re: Catching fork() with tied STDERR

Tieing STDERR doesn't always work out right. Some of perl's internal calls will ignore it, and continue to send their messages over the old STDERR. A separate program launched with system will commonly ignore it, too. In short, I don't think this is the last of your problems.

For a quick fix, for this particular problem, look into IPC::Open3, and run the check as a separate script. It'll send its STDOUT/STDERR nicely over a couple of handles you can read from, and forward to your own STDERR.

Comment on Re: Catching fork() with tied STDERR

Replies are listed 'Best First'.
Re: Re: Catching fork() with tied STDERR by hv (Prior) on May 01, 2004 at 13:23 UTC
Hmm, if any of perl's internal calls are ignoring it without a good reason (I guess a "panic: interpreter is broken" would be a good reason) then that's probably a bug that should be fixed; in any case, the underlying `STDERR` still points to the standard Apache error log, so such messages won't be lost entirely. (And in fact that seems like the real benefit of the tie - if anything goes horribly wrong in the logging code, the fallback is as simple as `untie STDERR`.) In general, if anything is calling out to a separate process I'd expect it to be handling STDERR from that itself - exactly as Email::Valid is trying to do - so I don't think that's a problem either. The issue as I see it is making sure I get out of the way of such child processes, so that they are actually able to handle STDERR themselves. And to do that, either I've got to know in advance that the child process will be created (as I now do for the MX check), or I have to get perl to tell me that it's about to happen (or has just happened). Hugo	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re: Re: Catching fork() with tied STDERR
by hv (Prior) on May 01, 2004 at 13:23 UTC

Hmm, if any of perl's internal calls are ignoring it without a good reason (I guess a "panic: interpreter is broken" would be a good reason) then that's probably a bug that should be fixed; in any case, the underlying *STDERR still points to the standard Apache error log, so such messages won't be lost entirely. (And in fact that seems like the real benefit of the tie - if anything goes horribly wrong in the logging code, the fallback is as simple as untie *STDERR.)

In general, if anything is calling out to a separate process I'd expect it to be handling STDERR from that itself - exactly as Email::Valid is trying to do - so I don't think that's a problem either.

The issue as I see it is making sure I get out of the way of such child processes, so that they are actually able to handle STDERR themselves. And to do that, either I've got to know in advance that the child process will be created (as I now do for the MX check), or I have to get perl to tell me that it's about to happen (or has just happened).

Hugo

[reply]
[d/l]
[select]