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 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