Am 16.11.2010 um 23:26 schrieb Robert Schetterer:

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

Well it does not start at all when it throws that. So it's kind of a deadly ultimate warning.

Thomas

Am 17.11.2010 um 05:15 schrieb Timo Sirainen:

...

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.

Guess it's not committed there yet as I'm pulling from Stephan's auto-build repo. As for 'lmtp' I remember seeing the same error for that as well, so not sure what other services would also miss the defaults. Stopped trying after those two...

Am 17.11.2010 um 06:01 schrieb Timo Sirainen:

It's there: http://hg.rename-it.nl/dovecot-2.0-pigeonhole/rev/c2a76570d736

I don't know about autobuild repos though.

Pulled another source this morning and it did not seem to work.

...

As for 'lmtp' I remember seeing the same error for that as well, so not sure what other services would also miss the defaults. Stopped trying after those two...

LMTP shouldn't have had that problem.. Unless you've explicitly changed those in the config file? See doveconf -n|grep vsz_limit

No defaults changed here. Verified with grep. It threw the same error on '20-lmtp.conf' after I manually set a default for '20-managesieve.conf'.

Am 17.11.2010 09:28, schrieb Thomas Leuxner:

On Wed, Nov 17, 2010 at 05:01:27AM +0000, Timo Sirainen wrote:

...

LMTP shouldn't have had that problem.. Unless you've explicitly changed those in the config file? See doveconf -n|grep vsz_limit

Did some investigation now and could bring up the latest and greatest by adding missing defaults after comparing an old 'doveconf -a' dump:

[ 20-managesieve.conf ]

• vsz_limit = 64M

Manually uncommented the entry in the file.

It then gave me:

$ invoke-rc.d dovecot start Starting IMAP/POP3 mail server: dovecotdoveconf: Fatal: Error in configuration file /etc/dovecot/dovecot.conf: service(lmtp): vsz_limit is too low failed!

Previous settings would indicate default of:

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

That does not work anymore though. Manually set a size in 'master.conf' therefore:

[ 10-master.conf ]

service lmtp { [...] vsz_limit = 64M }

Now Dovecot comes up. Not sure what value would be reasonable for the LMTP Service. Point is: It should pull reasonable defaults which it obviously does not.

Regards Thomas

i think there can only be defaults if all parameters are default ( at a new clean install from scratch )

cause there are depencies, so if you change one parameter ,others might be changed too, at last ,using distro packs, may also change default setups to what the distro releaser means that is best, so Timo might not the right man ,to talk to in such case...

perhaps others might mean the better way is to let dovecot start with warning and let it crash later....

i think in this case ,there is no "make all people happy" chance

so the only problem might have been not reading changelogs or/and better anouncement to new stuff,

lucky Timo is patching fast and quick, on the other Hand people arent that quick as Timo *g, so everything has its pros and contras perhaps it might be better to have a devel tree, but as far i see Timo is the main coder so its definite up to him how to handle releasing, unless there are no other prime coders to which he has to sync, and i think Timo would be happy if there would be more heavy coders at dovecot for better testing,releasing,coding etc

but after all its not a heavy problem, there might be always trouble with latest code so be prepared at upgrade, make sure that you can get back at productional servers

why no use something like i.e default_vsz_limit = 256M ? instead of using seperate entries

-- Best Regards

MfG Robert Schetterer

Germany/Munich/Bavaria

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 11:00, schrieb Robert Schetterer:

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

ok, for info

i have 2.0.7-0~auto+6 which is latest current on http://xi.rename-it.nl/debian/ yet

needed i.e service lmtp { vsz_limit = 256M ...

at my setup !!!

changelog of this version , so looks like current in sync with latest patch level

dovecot (2:2.0.7-0~auto+6) unstable; urgency=low

• New revision (1445:c2a76570d736) in pigeonhole Mercurial repository:
  • Services' default vsz_limit wasn't actually using default_vsz_limit but rather 4 GB.
  • "Running standalone?" check now uses a new DOVECOT_CHILD_PROCESS environment rather than GENERATION.

-- Stephan Bosch stephan@rename-it.nl Tue, 16 Nov 2010 23:10:56 +0200

dovecot (2:2.0.7-0~auto+5) unstable; urgency=low

• New revision (12432:8793036f6de8) in dovecot Mercurial repository:
  • Services' default vsz_limit wasn't actually using default_vsz_limit but rather 4 GB.
  • Fixed home=/home/./user style chrooting to work again.
  • master: Fail if service's vsz_limit is less than 1 kB
  • imap/pop3-login: Default vsz_limit=64 caused it to be unlimited, not 64 MB.

-- Stephan Bosch stephan@rename-it.nl Tue, 16 Nov 2010 21:19:17 +0200

dovecot (2:2.0.7-0~auto+4) unstable; urgency=low

....

-- 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.