On Fri Apr 25, 2008 at 09:44:00 +0200, Jose Luis Martinez wrote: > It seems that DBI at destruction time is doing something bad... but I > can't trace the code down to what it's doing, and why only when TLS > session is active, and only (until another pattern is detected) when a > "DATA" without line terminator is issued and connection is closed.
> Has anyone had the oportunity to reproduce the bug? I've seen problems with DBI under qpsmtpd, but I didn't pipe up earlier because my symptoms are different than yours. I use a singleton module to gain access to the DBI instance, code almost identical to this here (additional code added to ensure the connection is ping()d and re-opened if it went away) http://yawns.repository.steve.org.uk/?file/tip/Singleton/DBI.pm All of my plugins have code like this: sub foo { my( $self, $transaction, $.... ) = ( @_); my $cache = Singleton::Memcached->instance(); my $dbi = Singleton::DBI->instance(); ... } This basic usage works just fine *unless* I try to update the database. ie. SELECT queries are handled properly, always. UPDATEs are not. Looking around I think that my problem is that qpsmtpd creates the connection to the database prior to a fork - and that this fork()d handle is copied around to the children causing issues. (I'm using qpsmtpd-forkserver on Debian Etch; I'd love to try the Danga version, even if it meant I needed to rewrite stuff, but I can't find any compressive documentation on usage..) Looking on perlmonks there are reports of people seeing random problems if they fork() and use DBI without special care. I can't see from your description that this is your problem - hence my earlier silence. > I think that plugin timeouts, if necessary, have to be very well thought > and discussed... And if they will hurt performance, just to get "badly" > designed plugins to timeout, maybe they are not necessary. For badly, I'm > referring to plugins that will not timeout by themselves. Perhaps /etc/qpsmtpd/(plugin-)timeout to make it configurable? My plugins, FWIW, are expected to finish "immediately". So five minutes would be fine. > > Jose Luis Martinez > CAPSiDE > [EMAIL PROTECTED] > Steve -- # The Debian Security Audit Project. http://www.debian.org/security/audit
