Re: Fork child

Does the STDERR get closed automatically when I fork?

That presumably depends on the web server... Apache (mod_cgi), for example, does not close stderr (and your fork itself doesn't either), so any stuff written to stderr should by default end up in the web server's error log.

OTOH, if you have a long running script that you want to dissociate from the Apache process serving the request, you'd have to close STDERR yourself — else the connection would 'hang' (as with STDOUT). Or better yet, re-open STDERR to somewhere else.

Comment on Re: Fork child Select or Download Code

Replies are listed 'Best First'.
Re^2: Fork child by gayathriAthreya (Novice) on Dec 03, 2008 at 18:20 UTC
Usually just closing STDOUT worked. I never had to close STDERR explicitly. And I have been thinking about ways to capture error messages. The only thing I could come up with was to put an eval around the code, so that if something fails, I would know. But I would really like to be able to see warnings and such. Thanks!	[reply]
Re^3: Fork child by almut (Canon) on Dec 03, 2008 at 18:38 UTC
Usually just closing STDOUT worked. That's contrary to my experience with a default Apache / `mod_cgi` setup. I've always had to close both STDOUT and STDERR to cleanly dissociate a long running process. But as it looks (you don't seem to find the error messages anywhere), there is some configuration variant, with which stderr is being closed for CGIs (or rather, no pipe for stderr is being set up in the first place...). In that case, you of course wouldn't have to close it another time. I have been thinking about ways to capture error messages Why not just reopen STDERR to some file? Or maybe `use CGI::Carp "fatalsToBrowser";` — or, more generally, `carpout` ("fatalsToBrowser" of course wouldn't make sense for any long running process, as the connection to the browser would no longer be established in that case). Anyhow, more details about your configuration might help...	[reply] [d/l] [select]