>-----Original Message-----
>From: Jeremy Kitchen [mailto:[EMAIL PROTECTED]
>Sent: Friday, May 20, 2005 8:27 AM
>To: vchkpw@inter7.com
>Subject: Re: [vchkpw] read DB vs. write / update DB - Qmail, Vpopmail
>(authvchkpw & Mysql replication), Courier-pop3d
>On Friday 20 May 2005 09:48 am, Shane Metler wrote:
>> Hi list,
>> I have a Qmail cluster running, using Gentoo's patched versions of
>> Qmail, vpopmail (using MySQL replication), Courier-imap, and then
>> Courier-authlib linked to authvchkpw for IMAP & POP3 authentication.
>> qmail-1.03
>> vpopmail-5.4.6
>> courier-imap-4.0.1
>> courier-authlib-0.55
>> MySQL replication is set up with a remote Master server for
>> writes/updates, and a local Slave server for authentication reads.
>> This setup works fine. MySQL is replicating, SMTP and POP3
>> authentication is working, and all mail delivery is fine ... On the
>> surface there are no issues with these mail servers.
>> But I noticed (while testing POP3 connections) that both the read and
>> the write MySQL servers have persistent connections opened up (user:
>> vpopsqluser, table: vpopmail ) after checking mail once via POP3.
>all vpopmail processes are short lived.  If there is an open mysql
>for any reason for more than about 3 seconds, there's a bug.
>I would recommend upgrading to a newer version, as I believe this bug has
>Then again, I would also recommend removing gentoo's qmail ebuilds and
>installing it by hand.. but that's a discussion for another day.
>Jeremy Kitchen ++ Systems Administrator ++ Inter7 Internet Technologies,
>    [EMAIL PROTECTED] ++ inter7.com ++ 866.528.3530 ++ 815.776.9465 int'l
>      kitchen @ #qmail #gentoo on EFnet IRC ++ scriptkitchen.com/qmail
>         GnuPG Key ID: 481BF7E2 ++ jabber:[EMAIL PROTECTED]

I too have seen this behavior. Running vpopmail 5.4.7 with everything built
from source. I am still using courier 3.0.8, so I believe this issue to be
in vpopmail somewhere, most likely vchkpw. I do not have logging going to
the mysql server, so in essence there should be no need to write. It is
frustrating to have a cluster built using replication and then still have a
single point of failure. If my mysql master goes down for whatever reason,
then it doesn't matter how many other hosts I have to handle requests or how
solid my file server is, authentication will fail and my users can't get in.

I have not seen any notes in the change logs about this being fixed or else
I just flat out missed it. Can't say that I have problems with "persistent"
connections, however, I would like to see true use of the read/write setup.
Would be happy to supply more info.


Reply via email to