Re: [SOLVED] Re: How to run shell command from response handler? (Apache2 child segmentation fault)

Hi Jon,

My code actually needed to run other shell commands.  I just used the
`date` function as a simple example to demonstrate the problem.  

David

On Sat, 2012-01-07 at 02:44 -0700, Jon wrote:
> Hello All,
> 
> 
> Ok, maybe I'm missing the whole point of this thread, but why is this
> solution better than using the built-in perl `date` function?
> 
> 
> Personally, I think using the system 'date' function provides too many
> variables [read: problems] when attempting cross-platform continuity.
>  
> 
> 
> Maybe I have misunderstood the whole point of this thread, but it
> seems to me that everyone is over-engineering the problem... (i've
> only been a Perl programmer for like three years, so I still have
> ton's to learn... hopefully I can learn from this if I'm  way off
> base)
> 
> 
> Thanks,
> Jon A
> 
> On Tue, Jan 3, 2012 at 8:38 PM, David Booth <[email protected]> wrote:
>         Thanks for the suggestion.  I tried it with prefork and the
>         problem
>         still occurred.  HOWEVER, I then decided to remove all modules
>         down to a
>         minimal example, and discovered that the mere inclusion of the
>         following
>         module:
>         
>          use Test::MockObject;
>         
>         was causing the segmentation fault after several successful
>         requests,
>         even though no functions whatsoever were called.  Since this
>         appears to
>         be a bug in Test::MockObject, I reported the bug here:
>         https://rt.cpan.org/Public/Bug/Display.html?id=73723
>         
>         The bug report shows the exact minimal handler code that I
>         used to
>         reproduce the bug.
>         
>         Best wishes,
>         David
>         
>         
>         On Tue, 2012-01-03 at 17:26 -0500, Daniel Risacher wrote:
>         > I think I've been bitten by this too, years ago.
>         >
>         > I *think* I solved it by switching to mpm_prefork, which was
>         > unsatisfying, but adequate for my needs.
>         >
>         > On Tue, Jan 3, 2012 at 5:21 PM, David Booth
>         <[email protected]> wrote:
>         > > I tried redirecting stderr to /dev/null and it did not
>         help:
>         > > system("date >> $f 2> /dev/null");
>         > >
>         > > I am using the worker processing model.  Does it work for
>         you (or anyone
>         > > else) without causing periodic child process segmentation
>         faults?
>         > >
>         > >
>         > > On Tue, 2012-01-03 at 16:29 -0500, Daniel Risacher wrote:
>         > >> It's been a while since I looked at doing this, but IIRC
>         it's fairly
>         > >> dependent on the processing model that Apache is using.
>          Are you
>         > >> mpm_prefork, or mpm_worker?
>         > >>
>         > >> Also, I found it was important to redirect stderr
>         to /dev/null:
>         > >>
>         > >> sub play {
>         > >>     system "/usr/bin/xmms -t 2> /dev/null";
>         > >> }
>         > >>
>         > >>
>         > >> On Tue, Jan 3, 2012 at 12:48 PM, David Booth
>         <[email protected]> wrote:
>         > >> > I am trying to run a shell command from a mod_perl2
>         response handler.
>         > >> > It works properly for some number of HTTP requests, but
>         sometimes it
>         > >> > fails (somewhat randomly) and I see in my Apache2 error
>         log that one of
>         > >> > the Apache2 child processes has died with a
>         segmentation fault.
>         > >> > For example, /var/log/apache2/error.log shows:
>         > >> >
>         > >> > [Tue Jan 03 12:16:10 2012] [notice] child pid 3538 exit
>         signal Segmentation fault (11)
>         > >> >
>         > >> > Is this normal?  How does one normally run a shell
>         command from a
>         > >> > response handler?  I do not want to return the
>         command's output to the
>         > >> > client.
>         > >> >
>         > >> > Here is a trivial example response handler that
>         exhibits this behavior:
>         > >> >
>         > >> > sub handler
>         > >> > {
>         > >> > my $r = shift || die;
>         > >> > my $f = $ENV{DOCUMENT_ROOT} . "/date.txt";
>         > >> > system("date >> $f");
>         > >> > $r->internal_redirect("/date.txt");
>         > >> > return Apache2::Const::OK;
>         > >> > }
>         > >> >
>         > >> > Can anyone provide any guidance?  Does this work for
>         you?
>         > >> >
>         > >> > Note that you may not notice the problem if you don't
>         carefully watch
>         > >> > the Apache2 error log (e.g., with "tail
>         -f /var/log/apache2/error.log"),
>         > >> > because Apache2 automatically spawns new children
>         processes as needed,
>         > >> > and client (such as Firefox or wget, though not curl)
>         seem to
>         > >> > automatically re-try the request when it fails, thus
>         giving the illusion
>         > >> > of succeeding.
>         > >> >
>         > >> > P.S. I have posted about this on perlmonks, but thus
>         far have not found
>         > >> > a solution:
>         > >> > http://www.perlmonks.org/?node_id=945947
>         > >> >
>         > >> >
>         > >> > --
>         > >> > David Booth, Ph.D.
>         > >> > http://dbooth.org/
>         > >> >
>         > >> > Opinions expressed herein are those of the author and
>         do not necessarily
>         > >> > reflect those of his employer.
>         > >> >
>         > >>
>         > >>
>         > >
>         > > --
>         > > David Booth, Ph.D.
>         > > http://dbooth.org/
>         > >
>         > > Opinions expressed herein are those of the author and do
>         not necessarily
>         > > reflect those of his employer.
>         > >
>         >
>         >
>         
>         --
>         David Booth, Ph.D.
>         http://dbooth.org/
>         
>         Opinions expressed herein are those of the author and do not
>         necessarily
>         reflect those of his employer.
>         
>         
> 
> 
> 
> 
> -- 
> Best Regards,
> Jonathan David
> 
> 
> Please excuse any brevity or typos as this e-mail is most likely sent
> from a mobile device.
> 
> 

-- 
David Booth, Ph.D.
http://dbooth.org/

Opinions expressed herein are those of the author and do not necessarily
reflect those of his employer.