[afnog] Courier-Imapd: FAM Errors and Periodic Authentication Failures

[Begumisa Gerald M]

Hi Brian, Noah,

Thanks for the responses!  The problem has been partially solved (the
MySQL authentication part).  See below.

      On Thu, 5 Jan 2006, Brian Candler wrote:
    > Versions of all software?

Just for the record, I'm using courier-imap-4.0.6 - I've fixed the problem
though as I detail later in this email.

    > Each authdaemond instance should hold open a persistent connection
    > to the mysql database.
    >
    > So, how many authdaemond instances are you running (MAXDAEMONS in
    > authdaemonrc)? Does mysql have any limit as to the number of
    > concurrent connections it will accept?

There are 6 authdaemond instances running.  Your hint reminded me that I
did change the MySQL password authdaemond is supposed to use, after which
I restarted the authdaemond process using
"/usr/local/etc/rc.d/courier-authdaemond.sh restart".  It looks like one
of the processes remained running with the old password setting after all
- hence the ~ 1 in 7 failure rate.

So, what I did was to stop ALL authdaemond processes and start it once
again.  I've done multiple tests and all seems to be well now.

Thanks for the hint!

    > Personally I would remove fam completely, then rebuild courier-imap
    > again. Modify the port to remove the dependency if necessary.

I think this is the path I'm going to take, as well.

I've actually been troubleshooting this for quite a while and haven't come
up with much.  What I have realised, though, is that when you run the
"fam" program as a daemon (e.g by issuing the command
"/usr/local/bin/fam &"), for *one* IMAP request, you'll not get the nasty
complaints in your log file.

It appears that after this *one* request, the "fam" daemon then dies
mysteriously and the errors start showing up once again.

The way I understand it, though, is that inetd is supposed to listen on
the appropriate port for us and call the "fam" program when necessary...
I think I'll kinda give up for now, remotely troubleshooting over a slow
link is abit tiring :-)



Regards,
Gerald.