Carp.pm reboots apache

[guillo]

I have this problem where my Apache constantly reboots. This is the error message as shown on the Apache Logs.
The Carp.pm file is calling for an exit.

Code: Select all

ModPerl::Util::exit: (120000) exit was called at C:/PROGRA~1/OTRS/OTRS/Kernel/cpan-lib/CGI/Carp.pm line 561[Tue Nov 20 14:54:44 2012] [notice] Parent: child process exited with status 255 -- Restarting.
Scalars leaked: 1
Scalars leaked: 1
Scalars leaked: 1
[Tue Nov 20 14:54:46 2012] [notice] Apache/2.2.17 (Win32) mod_apreq2-20090110/2.7.1 mod_perl/2.0.4 Perl/v5.12.3 configured -- resuming normal operations
[Tue Nov 20 14:54:46 2012] [notice] Server built: Oct 18 2010 01:58:12
[Tue Nov 20 14:54:46 2012] [notice] Parent: Created child process 6076
Scalars leaked: 1
Scalars leaked: 1
Scalars leaked: 1
[Tue Nov 20 14:54:49 2012] [notice] Child 6076: Child process is running
[Tue Nov 20 14:54:49 2012] [notice] Child 6076: Acquired the start mutex.
[Tue Nov 20 14:54:49 2012] [notice] Child 6076: Starting 64 worker threads.
[Tue Nov 20 14:54:49 2012] [notice] Child 6076: Starting thread to listen on port 80.
Scalars leaked: 1

And this is the line it complains about

Code: Select all

if ($r->bytes_sent) {
      $r->print($mess);
      $mod_perl == 2 ? ModPerl::Util::exit(0) : $r->exit;   <---------- line 561
    }

And this the code segment where the problem lies:

Code: Select all

if ($mod_perl) {
    my $r;
    if ($ENV{MOD_PERL_API_VERSION} && $ENV{MOD_PERL_API_VERSION} == 2) {
      $mod_perl = 2;
      require Apache2::RequestRec;
      require Apache2::RequestIO;
      require Apache2::RequestUtil;
      require APR::Pool;
      require ModPerl::Util;
      require Apache2::Response;
      $r = Apache2::RequestUtil->request;
    }
    else {
      $r = Apache->request;
    }
    # If bytes have already been sent, then
    # we print the message out directly.
    # Otherwise we make a custom error
    # handler to produce the doc for us.
    if ($r->bytes_sent) {
      $r->print($mess);
      $mod_perl == 2 ? ModPerl::Util::exit(0) : $r->exit; <----line 561
    } else {
      # MSIE won't display a custom 500 response unless it is >512 bytes!
      if ($ENV{HTTP_USER_AGENT} =~ /MSIE/) {
        $mess = "<!-- " . (' ' x 513) . " -->\n$mess";
      }
      $r->custom_response(500,$mess);
    }
  } else {
    my $bytes_written = eval{tell STDOUT};
    if (defined $bytes_written && $bytes_written > 0) {
        print STDOUT $mess;
    }
    else {
        print STDOUT "Status: 500\n";
        print STDOUT "Content-type: text/html\n\n";
        print STDOUT $mess;
    }
  }

This happens around 70 times a day.

At first I thougt that this would be an Apache problem but I lean towards a PERL error. Something is calling that exit. Even worse, sometimes this error happens two times in less than a minute. When it happens my users see the "website not found" screen. Any ideas what could be the reason for this behavior?

[guillo]

ANybody?

[jojo]

switch to a newer version of OTRS on windows or much better switch to a Linux based system

[guillo]

switch to a newer version of OTRS on windows or much better switch to a Linux based system

Will do...deffinitly.

In the meantime i'll have to find another solution.

[Sofia]

I have had the same problem with OTRS 3.0.10 and have done some research. It seems that except from copying libmysql.dll to system32 I also had to adjust the MaxRequestPerChild value from 0 (unlimited) to something more controlled in order to prevent memory leak in Apache. We're on a very small scale installation (Windows 2003 with just handful of users) and I tried to set the MaxRequestPerChild to 250 as a first try:

# WinNT MPM
# ThreadsPerChild: constant number of worker threads in the server process
# MaxRequestsPerChild: maximum number of requests a server process serves
<IfModule mpm_winnt_module>
ThreadsPerChild 150
MaxRequestsPerChild 250
</IfModule>

This is set in httpd-mpm.config and as I could find 3 different and don't know which one was the one i use I did a abckup of all 3 and changed this value in all of them.
This really did the trick and our OTRS went from very unstable to rather stable but a bit slow. The errorlog was reduced heavily by this and we also got much less crashes noted in the Windows eventviewer. Sideeffect is that the errorlog now is filled with
[error] [Fri Feb 15 11:20:11 2013] -e: APR does not understand this error code at C:/OTRS/OTRS//Kernel/Output/HTML/Layout.pm line 1545 instead.

We don't experience any errors in the usage of OTRS when these happens and I assume they are due to limited thread-handling and will disappear when we find a reasonable value.

We also restart the services twice per day to release any locked memory from the leak and this works fine so far.

I hope this helps someone else of you out there. If anyone have input on the APR error I appreciate it!