On 9.11.2010, at 23.49, Mark Moseley wrote:
> On Tue, Nov 9, 2010 at 3:05 PM, Timo Sirainen <t...@iki.fi> wrote:
>> On 9.11.2010, at 22.14, Mark Moseley wrote:
>>
>>> service imap {
>>> service_count = 0
>>> }
>>>
> Would the risks involved be identical to your warnings about using
> "service_count=0" with pop3-login/imap-login, namely that if the
> daemon gets hacked, it'd be able to access other mailboxes (presumably
> that the imap/pop3 already had open)?
If all your users share the same UID and there was a security hole in
imap/pop3, you could access everyone's mails regardless of this setting.
(Except if you also enabled chroots, but then you couldn't use this setting.)
> Nice, it does indeed seem to burn a lot less CPU. I've also set
> "process_min_avail=#" for 'service pop3' which appears to spread out
> incoming POP3 connections over all # pop3 procs. Any gotchas there?
> I've always got at least several hundred POP3 connections on a box, so
> having them not all hitting one proc is desirable. And having, say,
> 100 pop3 procs hanging around, possibly idle, is fine. This is pretty
> exciting stuff.
Should be fine.
> Anybody running this way in production on a large scale, i.e. using
> "service_count=0" in a "service imap" or "service pop3" ?
Only potential problem is memory leaks that keep increasing the memory usage.
Of course there should be no memory leaks. :) You could anyway set something
like service_count=1000 to get it to restart after handling 1000 connections.
