dovecot - Nov 2010 - Dovecot 2.0.7 (8793036f6de8) seems to miss some defaults for vsz_limit

Latest Mercurial seems to miss defaults for some services e.g.
'managesieve' and 'lmtp'. Example error message upon start:

dovecotdoveconf: Fatal: Error in configuration file /etc/dovecot/dovecot.conf:
service(managesieve-login): vsz_limit is too low failed!

Regards
Thomas

I believe Timo is already patching these.

On 11/16/10 16:09, Thomas Leuxner wrote:
> Latest Mercurial seems to miss defaults for some services e.g.
'managesieve' and 'lmtp'. Example error message upon start:
>
> dovecotdoveconf: Fatal: Error in configuration file
/etc/dovecot/dovecot.conf: service(managesieve-login): vsz_limit is too low
failed!
>
> Regards
> Thomas

Am 16.11.2010 22:09, schrieb Thomas Leuxner:
> Latest Mercurial seems to miss defaults for some services e.g.
'managesieve' and 'lmtp'. Example error message upon start:
> 
> dovecotdoveconf: Fatal: Error in configuration file
/etc/dovecot/dovecot.conf: service(managesieve-login): vsz_limit is too low
failed!
> 
> Regards
> Thomas
> 
i am not sure but i think this is a warning new to 2.0.7
high the limits or/and configure dependend parameters right and see if
it works

-- 
Best Regards

MfG Robert Schetterer

Germany/Munich/Bavaria

On 16.11.2010, at 21.09, Thomas Leuxner wrote:
> Latest Mercurial seems to miss defaults for some services e.g.
'managesieve' and 'lmtp'. Example error message upon start:
> 
> dovecotdoveconf: Fatal: Error in configuration file
/etc/dovecot/dovecot.conf: service(managesieve-login): vsz_limit is too low
failed!
Upgrade your pigeonhole too.

Am 17.11.2010 10:14, schrieb Thomas Leuxner:
> On Wed, Nov 17, 2010 at 09:57:59AM +0100, Robert Schetterer wrote:
>> i think there can only be defaults if all parameters are default
>> ( at a new clean install from scratch )
> 
> These are unset defaults as far as I can tell. As with all defaults they
> should work out of the box. They are *not* overriden by specific custom
> values. Well, actually they are now, because of not being set in the first
> instance.
hm i have i.e

# If you set service_count=0, you probably need to grow this.
  #vsz_limit = 64M


in 10-master.conf

so whatever there is/was a warning in some default conf having your eyes
on this parameter

so i stay
there can only be starting defaults at clean new setups
and they might fail too, i.e if you have very small resources
so give warning is the only chance i see

but no flame , i changed so much that i havent any idea whats now is
default exactly
> 
>> why no use something like i.e default_vsz_limit = 256M ?
>> instead of using seperate entries
> 
> Personally I think this is a form of wasting resources. Why would one
> allocate 256M to something that was previously set to 0B? Would it do
> any good at all? It may be convient to do so, but it may not be very
> effective...
sorry i have enough resources so i dont care
unless i see a warning, basicly i trust in Timos code giving the right
warnings

but good that Timo mostly answers if you ask detailed
describe your resources and he or others might give recomands
testing your setup with different setups might also help find out for
you, whats best at your site

perhaps some basic resource examples should be in the wiki
> 
> Thomas

-- 
Best Regards

MfG Robert Schetterer

Germany/Munich/Bavaria

Am 17.11.2010 10:40, schrieb Robert Schetterer:
> Am 17.11.2010 10:14, schrieb Thomas Leuxner:
>> On Wed, Nov 17, 2010 at 09:57:59AM +0100, Robert Schetterer wrote:
>>> i think there can only be defaults if all parameters are default
>>> ( at a new clean install from scratch )
>>
>> These are unset defaults as far as I can tell. As with all defaults
they
>> should work out of the box. They are *not* overriden by specific custom
>> values. Well, actually they are now, because of not being set in the
first
>> instance.
> 
> hm i have i.e
> 
> # If you set service_count=0, you probably need to grow this.
>   #vsz_limit = 64M
> 
> 
> in 10-master.conf
> 
> so whatever there is/was a warning in some default conf having your eyes
> on this parameter
> 
> so i stay
> there can only be starting defaults at clean new setups
> and they might fail too, i.e if you have very small resources
> so give warning is the only chance i see
> 
> but no flame , i changed so much that i havent any idea whats now is
> default exactly
> 
>>
>>> why no use something like i.e default_vsz_limit = 256M ?
>>> instead of using seperate entries
>>
>> Personally I think this is a form of wasting resources. Why would one
>> allocate 256M to something that was previously set to 0B? Would it do
>> any good at all? It may be convient to do so, but it may not be very
>> effective...
> 
> sorry i have enough resources so i dont care
> unless i see a warning, basicly i trust in Timos code giving the right
> warnings
> 
> but good that Timo mostly answers if you ask detailed
> describe your resources and he or others might give recomands
> testing your setup with different setups might also help find out for
> you, whats best at your site
> 
> perhaps some basic resource examples should be in the wiki
> 
>>
>> Thomas
> 
> 
 looking here
http://hg.dovecot.org/dovecot-2.0/
this seems to be fixed


-- 
Best Regards

MfG Robert Schetterer

Germany/Munich/Bavaria

On Wed, Nov 17, 2010 at 02:34:58PM +0000, Timo Sirainen
wrote:
> Oh, right, that was causing problems too. Fixed:
http://hg.dovecot.org/dovecot-2.0/rev/2456cd0917d3
service managesieve-login {
  [...]
  vsz_limit = 64 M
}

service lmtp {
  [...]
  vsz_limit = 0
}

Patched. Fixes both. Thanks Timo.