Apache2 session problems with rt 3.0.4

I posted earlier but didn’t give the complete error.
I’ve not been able to cure the problem, but the problem is alleviated
temporarily by restarting apache.

Thanks,
–Robert

Here’s the error:

                             System error

error: RT Couldn’t write to session directory ‘/opt/rt3/var/session_data’: DBD::
mysql::st execute failed: MySQL server has gone away at /usr/lib/perl5/
site_perl/5.8.0/Apache/Session/Lock/MySQL.pm line 54.

    Stack:
    [/usr/lib/perl5/site_perl/5.8.0/Apache/Session/Lock/MySQL.pm:54]
    [/usr/lib/perl5/site_perl/5.8.0/Apache/Session/Lock/MySQL.pm:60]
    [/usr/lib/perl5/site_perl/5.8.0/Apache/Session.pm:569]
    [/usr/lib/perl5/site_perl/5.8.0/Apache/Session.pm:497]
    [/usr/lib/perl5/site_perl/5.8.0/Apache/Session.pm:462]
    [/usr/lib/perl5/site_perl/5.8.0/Apache/Session/Lock/MySQL.pm:54]
    [/opt/rt3/share/html/autohandler:51]
    . Check that this dir ectory's permissions are correct. at /opt/rt3/share/html/
    Elements/SetupSessionCookie line 60.

context:

56: };
57: undef $cookies{‘RT_SID’};
58: }
59: else {
60: die “RT Couldn’t write to session directory ‘$RT::MasonSessionDir’: $@. Check
that this dir ectory’s permissions are correct.”;
61: }
62: }
63:
64: if ( !$cookies{‘RT_SID’} ) {

code stack: /opt/rt3/share/html/Elements/SetupSessionCookie:60
/opt/rt3/share/html/autohandler:51

/* And here’s the raw error */

RT Couldn’t write to session directory ‘/opt/rt3/var/session_data’: DBD::mysql::st execute failed: MySQL
+server has gone away at /usr/lib/perl5/site_perl/5.8.0/Apache/Session/Lock/MySQL.pm line 54.

Stack:
[/usr/lib/perl5/site_perl/5.8.0/Apache/Session/Lock/MySQL.pm:54]
[/usr/lib/perl5/site_perl/5.8.0/Apache/Session/Lock/MySQL.pm:60]
[/usr/lib/perl5/site_perl/5.8.0/Apache/Session.pm:569]
[/usr/lib/perl5/site_perl/5.8.0/Apache/Session.pm:497]
[/usr/lib/perl5/site_perl/5.8.0/Apache/Session.pm:462]
[/usr/lib/perl5/site_perl/5.8.0/Apache/Session/Lock/MySQL.pm:54]
[/opt/rt3/share/html/autohandler:51]
. Check that this dir ectory’s permissions are correct. at /opt/rt3/share/html/Elements/SetupSessionCookie
+line 60.

Trace begun at /usr/lib/perl5/site_perl/5.8.0/HTML/Mason/Exceptions.pm line 131
HTML::Mason::Exceptions::rethrow_exception(‘RT Couldn’t write to session directory
+’/opt/rt3/var/session_data’: DBD::mysql::st execute failed: MySQL server has gone away at
+/usr/lib/perl5/site_perl/5.8.0/Apache/Session/Lock/MySQL.pm line 54.^J^JStack:^J
+[/usr/lib/perl5/site_perl/5.8.0/Apache/Session/Lock/MySQL.pm:54]^J
+[/usr/lib/perl5/site_perl/5.8.0/Apache/Session/Lock/MySQL.pm:60]^J
+[/usr/lib/perl5/site_perl/5.8.0/Apache/Session.pm:569]^J
+[/usr/lib/perl5/site_perl/5.8.0/Apache/Session.pm:497]^J
+[/usr/lib/perl5/site_perl/5.8.0/Apache/Session.pm:462]^J
+[/usr/lib/perl5/site_perl/5.8.0/Apache/Session/Lock/MySQL.pm:54]^J [/opt/rt3/share/html/autohandler:51]^J.
+Check that this dir ectory’s permissions are correct. at /opt/rt3/share/html/Elements/SetupSessionCookie
+line 60.^J’) called at /opt/rt3/share/html/Elements/SetupSessionCookie line 60
HTML::Mason::Commands::ANON at /usr/lib/perl5/site_perl/5.8.0/HTML/Mason/Component.pm line 134
HTML::Mason::Component::run(‘HTML::Mason::Component::FileBased=HASH(0x8af256c)’) called at
+/usr/lib/perl5/site_perl/5.8.0/HTML/Mason/Request.pm line 1062
eval {…}(‘HTML::Mason::Component::FileBased=HASH(0x8af256c)’) called at
+/usr/lib/perl5/site_perl/5.8.0/HTML/Mason/Request.pm line 1056
HTML::Mason::Request::comp(undef, undef) called at /opt/rt3/share/html/autohandler line 51
HTML::Mason::Commands::ANON at /usr/lib/perl5/site_perl/5.8.0/HTML/Mason/Component.pm line 134
HTML::Mason::Component::run(‘HTML::Mason::Component::FileBased=HASH(0x8af16f0)’) called at
+/usr/lib/perl5/site_perl/5.8.0/HTML/Mason/Request.pm line 1062
eval {…}(‘HTML::Mason::Component::FileBased=HASH(0x8af16f0)’) called at
+/usr/lib/perl5/site_perl/5.8.0/HTML/Mason/Request.pm line 1056
HTML::Mason::Request::comp(undef, undef, undef) called at
+/usr/lib/perl5/site_perl/5.8.0/HTML/Mason/Request.pm line 333
eval {…}(undef, undef, undef) called at /usr/lib/perl5/site_perl/5.8.0/HTML/Mason/Request.pm line 333
eval {…}(undef, undef, undef) called at /usr/lib/perl5/site_perl/5.8.0/HTML/Mason/Request.pm line 290
HTML::Mason::Request::exec(‘HTML::Mason::Request::CGI=HASH(0x96a1104)’) called at
+/usr/lib/perl5/site_perl/5.8.0/HTML/Mason/Interp.pm line 207
HTML::Mason::Interp::exec(undef, undef) called at /usr/lib/perl5/site_perl/5.8.0/HTML/Mason/CGIHandler.pm
+line 87
HTML::Mason::CGIHandler::_handler(‘HTML::Mason::CGIHandler=HASH(0x8f62698)’, ‘HASH(0x9641dcc)’) called at
+/usr/lib/perl5/site_perl/5.8.0/HTML/Mason/CGIHandler.pm line 70
HTML::Mason::CGIHandler::handle_cgi_object(‘HTML::Mason::CGIHandler=HASH(0x8f62698)’,
+‘CGI::Fast=HASH(0x969bdd4)’) called at /opt/rt3/bin/mason_handler.fcgi line 50

I’ve got the same problem and I’m using the same workaround… As the
permissions of the directory are ok and in regard of the error message,
I guess it is related to a connection timeout of MySQL. Maybe the
Apache::Session module doesn’t check if its connection is up (and thus
don’t reconnect).

How do you run RT : mod_perl, fastcgi or speedycgi ?

Robert Nickel a écrit :

I posted earlier but didn’t give the complete error.
I’ve not been able to cure the problem, but the problem is alleviated
temporarily by restarting apache.

Thanks,
–Robert

Here’s the error:

                            System error

error: RT Couldn’t write to session directory ‘/opt/rt3/var/session_data’: DBD::
mysql::st execute failed: MySQL server has gone away at /usr/lib/perl5/
site_perl/5.8.0/Apache/Session/Lock/MySQL.pm line 54.

   Stack:
   [/usr/lib/perl5/site_perl/5.8.0/Apache/Session/Lock/MySQL.pm:54]
   [/usr/lib/perl5/site_perl/5.8.0/Apache/Session/Lock/MySQL.pm:60]
   [/usr/lib/perl5/site_perl/5.8.0/Apache/Session.pm:569]
   [/usr/lib/perl5/site_perl/5.8.0/Apache/Session.pm:497]
   [/usr/lib/perl5/site_perl/5.8.0/Apache/Session.pm:462]
   [/usr/lib/perl5/site_perl/5.8.0/Apache/Session/Lock/MySQL.pm:54]
   [/opt/rt3/share/html/autohandler:51]
   . Check that this dir ectory's permissions are correct. at /opt/rt3/share/html/
   Elements/SetupSessionCookie line 60.

context:

56: };
57: undef $cookies{‘RT_SID’};
58: }
59: else {
60: die “RT Couldn’t write to session directory ‘$RT::MasonSessionDir’: $@. Check
that this dir ectory’s permissions are correct.”;
61: }
62: }
63:
64: if ( !$cookies{‘RT_SID’} ) {

code stack: /opt/rt3/share/html/Elements/SetupSessionCookie:60
/opt/rt3/share/html/autohandler:51

/* And here’s the raw error */

RT Couldn’t write to session directory ‘/opt/rt3/var/session_data’: DBD::mysql::st execute failed: MySQL
+server has gone away at /usr/lib/perl5/site_perl/5.8.0/Apache/Session/Lock/MySQL.pm line 54.

Stack:
[/usr/lib/perl5/site_perl/5.8.0/Apache/Session/Lock/MySQL.pm:54]
[/usr/lib/perl5/site_perl/5.8.0/Apache/Session/Lock/MySQL.pm:60]
[/usr/lib/perl5/site_perl/5.8.0/Apache/Session.pm:569]
[/usr/lib/perl5/site_perl/5.8.0/Apache/Session.pm:497]
[/usr/lib/perl5/site_perl/5.8.0/Apache/Session.pm:462]
[/usr/lib/perl5/site_perl/5.8.0/Apache/Session/Lock/MySQL.pm:54]
[/opt/rt3/share/html/autohandler:51]
. Check that this dir ectory’s permissions are correct. at /opt/rt3/share/html/Elements/SetupSessionCookie
+line 60.

Trace begun at /usr/lib/perl5/site_perl/5.8.0/HTML/Mason/Exceptions.pm line 131
HTML::Mason::Exceptions::rethrow_exception(‘RT Couldn’t write to session directory
+’/opt/rt3/var/session_data’: DBD::mysql::st execute failed: MySQL server has gone away at
+/usr/lib/perl5/site_perl/5.8.0/Apache/Session/Lock/MySQL.pm line 54.^J^JStack:^J
+[/usr/lib/perl5/site_perl/5.8.0/Apache/Session/Lock/MySQL.pm:54]^J
+[/usr/lib/perl5/site_perl/5.8.0/Apache/Session/Lock/MySQL.pm:60]^J
+[/usr/lib/perl5/site_perl/5.8.0/Apache/Session.pm:569]^J
+[/usr/lib/perl5/site_perl/5.8.0/Apache/Session.pm:497]^J
+[/usr/lib/perl5/site_perl/5.8.0/Apache/Session.pm:462]^J
+[/usr/lib/perl5/site_perl/5.8.0/Apache/Session/Lock/MySQL.pm:54]^J [/opt/rt3/share/html/autohandler:51]^J.
+Check that this dir ectory’s permissions are correct. at /opt/rt3/share/html/Elements/SetupSessionCookie
+line 60.^J’) called at /opt/rt3/share/html/Elements/SetupSessionCookie line 60
HTML::Mason::Commands::ANON at /usr/lib/perl5/site_perl/5.8.0/HTML/Mason/Component.pm line 134
HTML::Mason::Component::run(‘HTML::Mason::Component::FileBased=HASH(0x8af256c)’) called at
+/usr/lib/perl5/site_perl/5.8.0/HTML/Mason/Request.pm line 1062
eval {…}(‘HTML::Mason::Component::FileBased=HASH(0x8af256c)’) called at
+/usr/lib/perl5/site_perl/5.8.0/HTML/Mason/Request.pm line 1056
HTML::Mason::Request::comp(undef, undef) called at /opt/rt3/share/html/autohandler line 51
HTML::Mason::Commands::ANON at /usr/lib/perl5/site_perl/5.8.0/HTML/Mason/Component.pm line 134
HTML::Mason::Component::run(‘HTML::Mason::Component::FileBased=HASH(0x8af16f0)’) called at
+/usr/lib/perl5/site_perl/5.8.0/HTML/Mason/Request.pm line 1062
eval {…}(‘HTML::Mason::Component::FileBased=HASH(0x8af16f0)’) called at
+/usr/lib/perl5/site_perl/5.8.0/HTML/Mason/Request.pm line 1056
HTML::Mason::Request::comp(undef, undef, undef) called at
+/usr/lib/perl5/site_perl/5.8.0/HTML/Mason/Request.pm line 333
eval {…}(undef, undef, undef) called at /usr/lib/perl5/site_perl/5.8.0/HTML/Mason/Request.pm line 333
eval {…}(undef, undef, undef) called at /usr/lib/perl5/site_perl/5.8.0/HTML/Mason/Request.pm line 290
HTML::Mason::Request::exec(‘HTML::Mason::Request::CGI=HASH(0x96a1104)’) called at
+/usr/lib/perl5/site_perl/5.8.0/HTML/Mason/Interp.pm line 207
HTML::Mason::Interp::exec(undef, undef) called at /usr/lib/perl5/site_perl/5.8.0/HTML/Mason/CGIHandler.pm
+line 87
HTML::Mason::CGIHandler::_handler(‘HTML::Mason::CGIHandler=HASH(0x8f62698)’, ‘HASH(0x9641dcc)’) called at
+/usr/lib/perl5/site_perl/5.8.0/HTML/Mason/CGIHandler.pm line 70
HTML::Mason::CGIHandler::handle_cgi_object(‘HTML::Mason::CGIHandler=HASH(0x8f62698)’,
+‘CGI::Fast=HASH(0x969bdd4)’) called at /opt/rt3/bin/mason_handler.fcgi line 50


rt-users mailing list
rt-users@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-users

Have you read the FAQ? The RT FAQ Manager lives at http://fsck.com/rtfm

Guillaume Perréal.

Responsable informatique,
Cemagref, groupement de Lyon,
France.

Tél: (+33) 4.72.20.87.87.
Fax: (+33) 4.78.47.78.75.
Site: http://www.lyon.cemagref.fr/

I’ve got the same problem and I’m using the same workaround… As the
permissions of the directory are ok and in regard of the error message,
I guess it is related to a connection timeout of MySQL. Maybe the
Apache::Session module doesn’t check if its connection is up (and thus
don’t reconnect).

How do you run RT : mod_perl, fastcgi or speedycgi ?

Oops. Sorry. Fastcgi.

–Robert

I guess it is related to a connection timeout of MySQL. Maybe the
Apache::Session module doesn’t check if its connection is up (and thus
don’t reconnect).

Reconnecting should be handled within the MySQL driver.
From perldoc DBD::mysql:

    o   DBD::mysql has a "reconnect" feature that handles the
        so-called MySQL "morning bug": If the server has dis-
        connected, most probably due to a timeout, then by
        default the driver will reconnect and attempt to exe-
        cute the same SQL statement again. However, this
        behaviour is disabled when AutoCommit is off: Other-
        wise the transaction state would be completely unpre-
        dictable after a reconnect.

Sebastian

Sebastian Flothow
sebastian@flothow.de

Because it reverses the logical flow of conversation.
Why is top posting frowned upon?

Am Mittwoch, den 30. Juli 2003, um 19:41, schrieb Guillaume Perr�al:

I guess it is related to a connection timeout of MySQL. Maybe the
Apache::Session module doesn’t check if its connection is up (and thus
don’t reconnect).

Reconnecting should be handled within the MySQL driver.
From perldoc DBD::mysql:

   o   DBD::mysql has a "reconnect" feature that handles the
       so-called MySQL "morning bug": If the server has dis-
       connected, most probably due to a timeout, then by
       default the driver will reconnect and attempt to exe-
       cute the same SQL statement again. However, this
       behaviour is disabled when AutoCommit is off: Other-
       wise the transaction state would be completely unpre-
       dictable after a reconnect.

Ok, so is AutoCommit off in the RT code? Or is this in the Apache module?
Lastly, can anyone think of a workaround? I’m not opposed to scripting the
restart of the web server every day (as this is an 8-5 box) and getting away
from the problem that way, but I’m wondering if others will be having this
issue on servers that are 24x7.

Thanks,
–Robert

Robert Nickel a écrit :>On 2003.07.30 20:00:20 +0000, Sebastian Flothow wrote:

Am Mittwoch, den 30. Juli 2003, um 19:41, schrieb Guillaume Perréal:

I guess it is related to a connection timeout of MySQL. Maybe the
Apache::Session module doesn’t check if its connection is up (and thus
don’t reconnect).

Reconnecting should be handled within the MySQL driver.
From perldoc DBD::mysql:

  o   DBD::mysql has a "reconnect" feature that handles the
      so-called MySQL "morning bug": If the server has dis-
      connected, most probably due to a timeout, then by
      default the driver will reconnect and attempt to exe-
      cute the same SQL statement again. However, this
      behaviour is disabled when AutoCommit is off: Other-
      wise the transaction state would be completely unpre-
      dictable after a reconnect.

Ok, so is AutoCommit off in the RT code? Or is this in the Apache module?
Lastly, can anyone think of a workaround? I’m not opposed to scripting the
restart of the web server every day (as this is an 8-5 box) and getting away
from the problem that way, but I’m wondering if others will be having this
issue on servers that are 24x7.

Thanks,
–Robert

It seems this problem is really related to FastCGI as it doesn’t happen
with mod_perl. I guess the Apache::Session module name doesn’t start
with Apache:: for nothing. I didn’t tested this with SpeedyCGI – by the
way, can someone send a working speedycgi setup on RedHat 8 or 9 ?

But well, as Red Hat’s mod_perl truncates POST uploads (even on 8.0,
just checked it)… choose what you prefer : no attachment or errors ?

Guillaume Perréal.

Responsable informatique,
Cemagref, groupement de Lyon,
France.

Tél: (+33) 4.72.20.87.87.
Fax: (+33) 4.78.47.78.75.
Site: http://www.lyon.cemagref.fr/

Robert Nickel a �crit :

Am Mittwoch, den 30. Juli 2003, um 19:41, schrieb Guillaume Perr�al:

I guess it is related to a connection timeout of MySQL. Maybe the
Apache::Session module doesn’t check if its connection is up (and thus
don’t reconnect).
Reconnecting should be handled within the MySQL driver.
From perldoc DBD::mysql:

 o   DBD::mysql has a "reconnect" feature that handles the
     so-called MySQL "morning bug": If the server has dis-
     connected, most probably due to a timeout, then by
     default the driver will reconnect and attempt to exe-
     cute the same SQL statement again. However, this
     behaviour is disabled when AutoCommit is off: Other-
     wise the transaction state would be completely unpre-
     dictable after a reconnect.

Ok, so is AutoCommit off in the RT code? Or is this in the Apache module?
Lastly, can anyone think of a workaround? I’m not opposed to scripting the
restart of the web server every day (as this is an 8-5 box) and getting
away
from the problem that way, but I’m wondering if others will be having this
issue on servers that are 24x7.

Thanks,
–Robert

It seems this problem is really related to FastCGI as it doesn’t happen
with mod_perl. I guess the Apache::Session module name doesn’t start
with Apache:: for nothing. I didn’t tested this with SpeedyCGI – by the
way, can someone send a working speedycgi setup on RedHat 8 or 9 ?

But well, as Red Hat’s mod_perl truncates POST uploads (even on 8.0,
just checked it)… choose what you prefer : no attachment or errors ?

Blarg!

Scripting the restart when I finish with this email.

If anyone comes up with a fix for this, I’d love to hear about it.

Thanks,
–Robert