Bug #50035

IMAP re-auth request

Added by Volodymyr Tomash about 2 years ago. Updated about 2 years ago.

Status:UpdatedStart date:10/21/2015
Priority:NormalDue date:
Assignee:Danny T% Done:
0%
Category:Scalix Server
Target version:All
Operation System:--
Milestones:

Description

Created attachment 8 [details]
Scalix Fatal.log (last 10000 lines)

This issue is a part of IMAP issues that we have faced after update to Scalix 12.5
description: Sometimes IMAP service could be not reachable. Before I thought that it happened only several times and for all users, but now I see that it happened no so rarely but for few users(not all) at the same time.
Users began to complain about the constant password re-asking.
I have added fatal fog where you can see periodic temporary IMAP issues.
As we have no so much IMAP sessions at the same time (~150-200) and we have IPAM session limit 1200, Idk why we get these messages:
[OM 24070] Debug message for Lab use :
imapSatAuthenticate:Could not register with Session Monitor. usr_Signon() returned: SIGNON LIMIT REACHED, errno: Success

History

#1 Updated by Alexey Bobyr about 2 years ago

@vth can you please turn on IMAP logging
and then count how many LOGIN imap comands there.
for e.g. (on test server with unstable code ) it looks like this
  1. grep 'LOGIN' ./imap\ log | wc -l
    223

I have tried to execute next command
#ab -n 50 -c 10 -A user:pwd 'https:/mailbox?output=xml'
and the number of LOGIN is same as was before
#grep 'LOGIN' ./imap\ log | wc -l
223

there can be situation when http client does not send session identifier with Auth data. when there are no session identifier it will get Auth data and will try to login again. Here can be a problem.
I will look at it from my side.

P.S. You can use 'ab' - ApacheBench to load system for e.g. -n 50 (total number of requests) -c 10 (concurent threads in mine case 10 threads which will send 50 requests)

#2 Updated by Richard Hall about 2 years ago

The SIGNON LIMIT REACHED error is generated when a particular user already has 17 active signons and attempts another one.

There is a general.cfg option that allows this limit to be increased:
MAX_SIGNON_PER_USER=nn
where 'nn' is the increased limit.

However it would be good to understand why there are so many active signons being created. What mail client is being used by the users who get this problem?

#3 Updated by Alexey Bobyr about 2 years ago

Stupid question but. What for we need to count MAX_SIGNON_PER_USER?
I assume MAX_SIGNON_PER_USER count will decrease when user will send 'logout' imap command, but if connection was dropped (internet problems etc) this count is also decreasing?

I think we should not limit user with MAX_SIGNON_PER_USER there must be limit for attempts with wrong password or user. This option is useful for development but not for production

#4 Updated by Richard Hall about 2 years ago

It's not a stupid question. This limit is partially historical from a time when only one or two active sessions was considered to be normal usage, and partially to have some sort of limit to prevent rogue clients consuming too much resource.

If the server detects that the socket is disconnected then a implicit logout for the session is performed. If the socket still appears to be 'live' then the session will remain active.

If there is a particular user that is suffereing from this problem I can turn server trace on for that user and we can see exactly what session activity there is.

#5 Updated by Volodymyr Tomash about 2 years ago

  • Subject changed from https://bugzilla.scalix.com/show_bug.cgi?id=50035 to IMAP re-auth request

#6 Updated by Dirk Ahrnke about 2 years ago

I noticed this message after migrating a mailbox to server version 12.5.1.14746.
This mailbox is opened by 3 IMAP-clients (2*TB, 1 Outlook) and a script which polls the mailbox every minute.
Given that the script did not show errors (I checked the logs) I'd guess that a "normal" client was affected.

In addition I can see lots of these errors in logs provided by a customer.

I am tending to accept the fact that current use cases will create much more sessions and we may consider that MAX_SIGNON_PER_USER should be increased or not be limited anymore.

#7 Updated by Volodymyr Tomash about 2 years ago

  • Status changed from Answered to Updated

Dirk Ahrnke wrote:

I noticed this message after migrating a mailbox to server version 12.5.1.14746.
This mailbox is opened by 3 IMAP-clients (2*TB, 1 Outlook) and a script which polls the mailbox every minute.
Given that the script did not show errors (I checked the logs) I'd guess that a "normal" client was affected.

In addition I can see lots of these errors in logs provided by a customer.

I am tending to accept the fact that current use cases will create much more sessions and we may consider that MAX_SIGNON_PER_USER should be increased or not be limited anymore.

Hello
Yes MAX_SIGNON_PER_USER should be increased
In most cases it relatted to users that using Mac OS mail client.
I have increased MAX_SIGNON_PER_USER to 100 and it is enough for us
I think we change set default value MAX_SIGNON_PER_USER
or at least set it explicitly by Installer in general.cfg

Also available in: Atom PDF