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 <da...@dbooth.org> 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.