I'm starting to use Gearman to get around this whole problem.  We use a lot of 
external processes for many things, so this issue wtih Apache2 really bit me 
hard in the bee-hind.  I've gone to great lengths to work around it, but so far 
the job queue approach seems to be the most elegant and least problematic 
approach.  Of course, the recommendation came from the gentle folks on this 
list originally.

Eric

________________________________
From: Heiko Weber [mailto:he...@wecos.de]
Sent: Thursday, February 18, 2010 3:22 AM
To: Salvador Ortiz Garcia
Cc: mod_perl list
Subject: Re: [mp2] mod_perl closes apache's stdin and/or stdout

Salvador,

to avoid such issues my "external" tasks don't use STDOUT, STDIN or STDERR. 
They take their parameters from control files and write their results back to a 
status file. This tasks don't send any output back to the browsers. As I said, 
usually some "sudo's to change some system settings.

Well, I could replace all system() calls and just store the task jobs into a 
database table, to schedule a background job with cron to check and complete 
this tasks, but then I lost the immediately feedback to the user/browser ... 
AND this is a lot of work for me -  unless I can exactly repeat the issue I am 
not sure if it is worth to try it.

Currently it feels to me like a "leakage", sometimes a httpd/mod_perl/process 
do something, and later (maybe when working on the next client request) STDOUT 
is closed. This makes it hard to create a sample program to repeat it. Within a 
single script I can do almost everything: call system(), open DBI connections, 
write to STDOUT, ... everything seems to be fine.

Heiko

Am 16.02.2010 um 23:26 schrieb Salvador Ortiz Garcia:

On 02/05/2010 12:16 PM, Heiko Weber wrote:
Hi André,

I know what you mean, and I can't agree with you - the server response time is 
really low - most pages are finished loading in less 1-2 seconds, and the 
overall load of the server is at a low level. I believe there is an issue, 
maybe something what Jon is talking about, I also using some "system()" call's 
to execute sendmail or sudo tasks, so maybe STDOUT really gets closed - I have 
no idea. I only see the abort messages in errorlog very frequent, maybe 3-4 per 
minute.

Heiko

Of course STDOUT, STDIN, and STDERR get closed, not by mod_perl but by apache. 
Every UNIX  process when demonized must close them to detach from its 
controling terminal.

Apache reopens STDERR to its log file, but STDOUT and STDIN remain closed.

Maybe de confusion arises from the fact that when executing a CGI the server 
connects them to the client socket, but in mod_perl you are in the deamon 
process space.

Please check "Advanced Programing in the UNIX environment", chapter 13: "Daemon 
processes" by W. Richard Stevens.

Regards.

Salvador.

--
Wecos <> Heiko Weber Computer Systeme
D-21644 Sauensiek <> Immenweg 5
he...@wecos.de<mailto:he...@wecos.de> <> 
http://www.wecos.de<http://www.wecos.de/>

_______________________________________________

This e-mail may contain information that is confidential, privileged or 
otherwise protected from disclosure. If you are not an intended recipient of 
this e-mail, do not duplicate or redistribute it by any means. Please delete it 
and any attachments and notify the sender that you have received it in error. 
Unless specifically indicated, this e-mail is not an offer to buy or sell or a 
solicitation to buy or sell any securities, investment products or other 
financial product or service, an official confirmation of any transaction, or 
an official statement of Barclays. Any views or opinions presented are solely 
those of the author and do not necessarily represent those of Barclays. This 
e-mail is subject to terms available at the following link: 
www.barcap.com/emaildisclaimer. By messaging with Barclays you consent to the 
foregoing.  Barclays Capital is the investment banking division of Barclays 
Bank PLC, a company registered in England (number 1026167) with its registered 
office at 1 Churchill Place, London, E14 5HP.  This email may relate to or be 
sent from other members of the Barclays Group.
_______________________________________________

Reply via email to