David Wheeler wrote:
Hi All,
I just ran into some very strange issues with connections to a
PostgreSQL database (using DBD::Pg) getting unceremoniously dropped by
my mod_perl application. I was getting error messages such as these:
[Tue Jul 22 13:21:44 2003] [error] [client 207.172.11.148] Unable to
turn AutoCommit off: DBD driver has not implemented the AutoCommit
attribute at /usr/local/lib/perl5/site_perl/5.8.0/Bric/Util/DBI.pm line
528, <GEN71> line 57.
Database handle destroyed without explicit disconnect at
/usr/local/lib/perl5/site_perl/5.8.0/Bric/Util/DBI.pm line 1661.
Database handle destroyed without explicit disconnect at
/usr/local/lib/perl5/site_perl/5.8.0/Bric/Util/DBI.pm line 1661.
commit ineffective with AutoCommit enabled at
/usr/local/lib/perl5/site_perl/5.8.0/Bric/Util/DBI.pm line 571.
Database handle destroyed without explicit disconnect at
/usr/local/lib/perl5/site_perl/5.8.0/Bric/Util/DBI.pm line 1661.
The PostgreSQL log had these errors:
FATAL: Socket command type H unknown
FATAL: Socket command type 0 unknown
LOG: pq_flush: send() failed: Broken pipe
After a great deal of experimentation and recompilation, I finally
identified Apache 1.3.28 as the culprit. When I reverted to 1.3.27, the
problem went away.
I had a look at the Apache changelog to see what might have caused this
issue in Apache 1.3.28, and the most relevant item I found was this:
*) Certain 3rd party modules would bypass the Apache API and not
invoke ap_cleanup_for_exec() before creating sub-processes.
To such a child process, Apache's file descriptors (lock
fd's, log files, sockets) were accessible, allowing them
direct access to Apache log file etc. Where the OS allows,
we now add proactive close functions to prevent these file
descriptors from leaking to the child processes.
[Jim Jagielski, Martin Kraemer]
Now it's possible that this affects mod_perl and its connections to
PostgreSQL, though I have no idea how. Could it be that mod_perl is one
of the 3rd party modules that's breaking this rule? Or could it be some
other change that led to this problem?
Note that although I replicated this problem on FreeBSD and on Mac OS X
(and had a report of the same issue from a Solaris user) with mod_perl
1.28 and 1.27, it disappeared when I ran Apache in single-process mode.
I'm guessing that the problem is with either a) Apache (ack!); b) The
way Apache binds mod_perl (I've got mod_perl 1.x statically compiled
against Apache 1.3.x, of course); or c) Something to do with the way DBI
or DBD::Pg does something. My guess is b, but wouldn't rule out a; c
would be pretty strange.
At any rate, does anyone have any idea what could be causing problems
such as these?
How does it behave under mod_cgi? if it's possible to write a test case to be
run-able under mod_cgi.
How mod_perl is related to running subprocesses?
Does your app spawn a subprocess? Apache::SubProcess provides the
cleanup_for_exec() perl API if you do. It's also documented in the mp1 guide.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@xxxxxxxxxx http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
|
