[Dovecot] auth socket goes away on reload

David Jonas djonas at vitalwerks.com
Thu Jun 3 21:09:44 EEST 2010


On 6/3/10 , Jun 3, 10:16 AM, William Blunn wrote:
> On 03/06/2010 17:35, David Jonas wrote:
>> We're using the SQLite backend for authentication of Postfix SASL. When
>> the db is replaced we HUP dovecot to close and reopen its connection.
>> During this time it appears the socket file is removed and Postfix
>> rejects the authentication attempt. From the logs:
>>
>> Jun  3 00:23:02 xxx dovecot: dovecot: SIGHUP received - reloading
>> configuration
>> Jun  3 00:23:02 xxx postfix/smtpd[14746]: warning: SASL: Connect to
>> private/auth failed: Connection refused
>> Jun  3 00:23:02 xxx postfix/smtpd[14746]: warning: unknown[dd.dd.dd.dd]:
>> SASL LOGIN authentication failed:
>> Jun  3 00:23:02 xxx postfix/smtpd[14746]: NOQUEUE: reject: RCPT from
>> unknown[dd.dd.dd.dd]: 554 5.7.1<user at example.com>: Relay access denied;
>> from=<user2 at example.com>  to=<user at example.com>  proto=ESMTP
>> helo=<localhost.localdomain>
>>
>> Jun  3 00:23:02 xxx postfix/smtpd[14930]: warning: unknown[dd.dd.dd.dd]:
>> SASL LOGIN authentication failed: Connection lost to authentication
>> server
>> Jun  3 00:23:02 xxx postfix/smtpd[14930]: lost connection after AUTH
>> from unknown[dd.dd.dd.dd]
>>
>> Is there an obvious way around this? I know I could somehow merge the
>> changes into the running sqlite db but that undermines the simplicity of
>> the design I have. Maybe a patch to reopen the db if it's replaced? Or
>> perhaps I should just switch to a different db format -- that's probably
>> the quickest/easiest solution. Any other ideas? There are about 20k
>> entries to deal with.
>
> It sounds like your updates arrive in the shape of entire-table updates.
>
> That is no problem. You can easily apply entire-table updates to the
> database without having to re-create the SQLite database file, and
> without having to tell Dovecot.
>
> Just create a new table (with a different name) inside the SQLite
> database file, with the new content, then snap it into place using a
> pair of table renames inside a transaction; then delete the old table.
>
> That way you don't need to re-create the database file or HUP Dovecot,
> and Dovecot will only ever see the old data or the new data.

That sounds reasonable, not sure why I didn't think of it! Thanks.



More information about the dovecot mailing list