[Dovecot] server is not imap4 compatible

[marco ghidinelli]

On Wed, Apr 22, 2009 at 10:25:41AM -0400, Timo Sirainen wrote:
> On Apr 22, 2009, at 4:12 AM, marco ghidinelli wrote:
>
>>>> Apr 20 16:21:17 harlock dovecot: imap-login: Disconnected: Shutting
>>>> down: rip=192.168.0.194, lip=10.70.0.1, TLS handshake
>>>
>>> "Shutting down" means that Dovecot really is being shut down or
>>> restarted. Is this not an expected restart? Does it happen at the  
>>> same
>>> time always? Maybe it's some cron job.
>>
>> no, of course this was NOT an expected restart.
>> i thought that it was a normal disconnection between the client and
>> the server.
>>
>> the "shutting down" messages appeared even on the previous 1.0.rc15
>> version, but not the "server not imap4 compatible" error.
>>
>> or maybe my users didn't tell me.  :)
>>
>> any idea?
>
> My idea is still the same: Client gets unexpectedly disconnected due to 
> Dovecot restart and the client thinks it's not connected to IMAP4  
> server. Try to figure out why Dovecot is getting restarted.

dovecot doesn't restart, and nothing try to restart it.

> It's not doing it alone.

maybe it's not a 'whole' restart, but just it drops some connections.

> Do you see "starting up" lines in logs showing that the 
> whole Dovecot was restarted?

no

> If not, do you see any "killed by signal" 
> lines in logs?

no. i got those lines only when i issue the 
/etc/init.d/postfix {start|restart}
commands.

> Perhaps the whole Dovecot isn't being restarted, but just 
> some buggy script/program is sending SIGTERMs to imap-login processes 
> more or less randomly for some reason..

i looked at the dovecot sources now, and i saw that:

# vi master/login-process.c +738

static int login_group_start_missings(struct login_group *group)
{
        if (group->set->login_process_per_connection &&
            group->processes >= group->set->login_max_processes_count &&
            group->listening_processes == 0) {
                /* destroy the oldest listening process. non-listening
                   processes are logged in users who we don't want to kick out
                   because someone's started flooding */
                if (group->oldest_prelogin_process != NULL &&
                    group->oldest_prelogin_process->initialized)
                        login_process_destroy(group->oldest_prelogin_process);
        }


my login_max_processes_count was 256, and my imap-login process is 
about 240, now i enhanced it to 512.

am i going into the right direction?