Hibernation disabled when mailbox selected
After setting imap_hibernate_timeout to 60s, I could not find any hibernated connections after a few hours. I tested hibernation and made an observation: IDLE'd imap sessions only hibernate if they don't have a mailbox SELECT'd, otherwise they never hibernate.
Is this the way it's supposed to work?
Joseph Tam <jtam.home@gmail.com>
On 18 Oct 2015, at 05:20, Joseph Tam <jtam.home@gmail.com> wrote:
After setting imap_hibernate_timeout to 60s, I could not find any hibernated connections after a few hours. I tested hibernation and made an observation: IDLE'd imap sessions only hibernate if they don't have a mailbox SELECT'd, otherwise they never hibernate.
Is this the way it's supposed to work?
What client is that? IDLE doesn't really make much sense when a mailbox isn't SELECTed, so I expected that all the clients would have something SELECTed.. But yeah, the code could be changed to support that.
On Sun, 18 Oct 2015, Timo Sirainen wrote:
After setting imap_hibernate_timeout to 60s, I could not find any hibernated connections after a few hours. I tested hibernation and made an observation: IDLE'd imap sessions only hibernate if they don't have a mailbox SELECT'd, otherwise they never hibernate.
Is this the way it's supposed to work?
What client is that?
That would be "openssl s_client". I do not recommend this as your regular mail reader -- the user interface sucks.
IDLE doesn't really make much sense when a mailbox isn't SELECTed, so I expected that all the clients would have something SELECTed.. But yeah, the code could be changed to support that.
If hibernate only works when a mailbox is not selected, and all IMAP client connections select a mailbox, then yeah, hibernate wouldn't be a very useful feature. I would guess that most of the imap processes running in most installation are in IDLE state with s SELECTed mailbox, so extending hibernate to work with these connections these would more useful.
Couldn't a small pool of imap-hibernate processes hold on to all these hibernated connections for maximal memory conservation, or would that break the security model dovecot uses?
Anyways, thanks for clearing up my confusion.
Joseph Tam <jtam.home@gmail.com>
On 18 Oct 2015, at 20:25, Timo Sirainen <tss@iki.fi> wrote:
On 18 Oct 2015, at 05:20, Joseph Tam <jtam.home@gmail.com> wrote:
After setting imap_hibernate_timeout to 60s, I could not find any hibernated connections after a few hours. I tested hibernation and made an observation: IDLE'd imap sessions only hibernate if they don't have a mailbox SELECT'd, otherwise they never hibernate.
Is this the way it's supposed to work?
What client is that? IDLE doesn't really make much sense when a mailbox isn't SELECTed, so I expected that all the clients would have something SELECTed.. But yeah, the code could be changed to support that.
Actually, it already works, so your problem is something different. Set mail_debug=yes and it'll log the reason why hiberation couldn't be done.
I've heard that some clients issue STATUS commands periodically and that causes them not to be hibernated. This is something that probably needs to be implemented by imap-hibernate at some point.
On Mon, 19 Oct 2015, Timo Sirainen wrote:
Actually, it already works, so your problem is something different. Set mail_debug=yes and it'll log the reason why hiberation couldn't be done.
imap(ono): Debug: Couldn't hibernate imap client: Couldn't
extract notifications fd: Filesystem notifications
not supported
You mentioned something about this, but I must have overlooked it.
Mailbox changes are noticed only if inotify/kqueue is enabled,
so without them the hibernation feature won't work well.
Solaris10 does not have support for this (but Solaris11 does have File Event Notification). Pity.
Joseph Tam <jtam.home@gmail.com>
participants (2)
-
Joseph Tam
-
Timo Sirainen