[Dovecot] Alpha4 pre-release, please upgrade
Please try if http://dovecot.org/nightly/dovecot-latest.tar.gz (or the CVS directly) works with you. I made a lot of changes to dovecot-auth, so I wouldn't want to make alpha4 release without some more testing in different environments. I'll release alpha4 in a few days, but it'll be basically same as this unless more bugs get fixed.
Some of the changes include:
IMAP: We might have sent extra EXPUNGE messages when output buffer got full. This could have caused various sorts of very bad behavior. This is the main reason why everyone should upgrade as soon as possible.
POP3: We sent duplicate replies for LIST command when output buffer got full. Probably caused Thunderbird's duplicate deletion bugs? (Although I thought someone checked that Dovecot's reply was correct when the bug occurred?)
pop3_uidl_format setting is now required to be explicitly set in configuration file for pop3 to work at all. I want to get rid of the old default setting which breaks Outlooks, and simply changing the default would break existing setups.
Multiple passdbs and userdbs of same type can now be added with different parameters. Some people asked about this earlier.
Authentication cache works now with other than SQL and LDAP passdbs. Some passdbs such as PAM require some additional settings to work. See example config file.
Some other fixes to authentication cache related to failure handling and non-plaintext authentication.
deny passdb wasn't working for non-plaintext authentication.
Well - after running it for 2 minutes - it seems to work - and it seems faster. Did you do anything to make it perform better?
Using MBOX.
On 16.10.2005, at 21:13, Marc Perkel wrote:
Well - after running it for 2 minutes - it seems to work - and it seems faster. Did you do anything to make it perform better?
Using MBOX.
No. Although I didn't exactly get what your last problem was. Was Dovecot just stuck there doing nothing, or was it actually doing lots of disk I/O or wasting CPU?
I meant - 2 minutes of experiencing it.
After Alpha 1 dovecot seemd to run slower. Both Alpha 2 and Alpha 3 seemed ver slow. It seemd that it was disk IO related. This one so far seems to be back to Alpha1 speeds.
Timo Sirainen wrote:
On 16.10.2005, at 21:13, Marc Perkel wrote:
Well - after running it for 2 minutes - it seems to work - and it seems faster. Did you do anything to make it perform better?
Using MBOX.
No. Although I didn't exactly get what your last problem was. Was Dovecot just stuck there doing nothing, or was it actually doing lots of disk I/O or wasting CPU?
On Sun, 2005-10-16 at 21:19 +0300, Timo Sirainen wrote:
No. Although I didn't exactly get what your last problem was. Was Dovecot just stuck there doing nothing, or was it actually doing lots of disk I/O or wasting CPU?
Could the locking method change have caused it? Maybe the slowness was due to lock timeouts.
johannes
On Sun, 2005-10-16 at 20:41 +0300, Timo Sirainen wrote:
Please try if http://dovecot.org/nightly/dovecot-latest.tar.gz (or the CVS directly) works with you. I made a lot of changes to dovecot-auth, so I wouldn't want to make alpha4 release without some more testing in different environments. I'll release alpha4 in a few days, but it'll be basically same as this unless more bugs get fixed.
Cheers Timo,
Will shove on my home server tonight and the hosting servers in the morning. Think it has all the fixes I wanted already :)
Regards Andrew
Andrew Hutchings (A-Wing) - Linux Guru Netserve Consultants - http://www.domaincity.co.uk/ Linux CDs and DVDs - http://www.linuxiso.co.uk/ Random quote 178: "Well, let's just say, 'if your VCR is still blinking 12:00, you don't want Linux'". - Bruce Perens, Debian's Fearless Leader
On Sun, Oct 16, 2005 at 08:41:55PM +0300, Timo Sirainen wrote:
Please try if http://dovecot.org/nightly/dovecot-latest.tar.gz (or the CVS directly) works with you. I made a lot of changes to dovecot-auth, so I wouldn't want to make alpha4 release without some more testing in different environments. I'll release alpha4 in a few days, but it'll be basically same as this unless more bugs get fixed.
I've been running alpha3 without any problems. However, the alpha4 pre-release drops my connection after a "SELECT INBOX" and leaves this in the logs:
dovecot: Oct 16 14:20:15 Info: imap-login: Login: user=<glenn>, method=PLAIN, rip=127.0.0.1, lip=127.0.0.1, secured dovecot: Oct 16 14:20:15 Error: imap(glenn): flock() locks not supported dovecot: Oct 16 14:20:15 Error: child 411 (imap) returned error 89
Here's truss output of imap:
read(0, " x s e l e c t I N B".., 4096) = 16 open64("/home/glenn/.inbox", O_RDWR|O_CREAT|O_EXCL, 0660) Err#17 EEXIST mkdir("/home/glenn/.imap/INBOX", 0770) Err#17 EEXIST stat64("/home/glenn/.imap/INBOX", 0xFFBFF468) = 0 time() = 1129488290 open64("/home/glenn/.imap/INBOX/dovecot.index", O_RDWR) = 4 alarm(120) = 0 write(2, "01 F f l o c k ( ) l o".., 30) = 30 _exit(89)
This looks like a locking issue on an index file. I had been leaving lock_method unset, letting it default to fcntl (inferred from the comments in dovecot-example.conf). I changed it to the explicit "lock_method = fcntl" and this fixed the problem.
Has the lock_method default changed from alpha3 to alpha4?
And is it proper to infer from the comment below in dovecot-example.conf that the default is supposed to be fcntl?
#lock_method = fcntlThanks, Glenn
-- Glenn Leavell glenn@usg.edu Office of Information and Instructional Technology Board of Regents of the University System of Georgia
On Sun, 2005-10-16 at 14:56 -0400, Glenn Leavell wrote:
dovecot: Oct 16 14:20:15 Error: imap(glenn): flock() locks not supported .. This looks like a locking issue on an index file. I had been leaving lock_method unset, letting it default to fcntl (inferred from the comments in dovecot-example.conf). I changed it to the explicit "lock_method = fcntl" and this fixed the problem.
Has the lock_method default changed from alpha3 to alpha4?
Yes. I forgot to mention this.
And is it proper to infer from the comment below in dovecot-example.conf that the default is supposed to be fcntl?
#lock_method = fcntl
Look at the dovecot-example.conf in the new tarball:
# Locking method for index files. Alternatives are fcntl, flock and dotlock. # Dotlocking uses some tricks which may create more disk I/O than other locking # methods. NOTE: If you use NFS, remember to change also mmap_disable setting! #lock_method = flock
The reason for this change was that I thought since so many people have /home mounted as NFS, the best way to inform them about NFS problems would be to fail completely until they have changed lock_method and also seen the note about mmap_disable.
Unfortunately flock() isn't supported at all with Solaris, so this is a bit of an extra trouble for Solaris users.
On Sun, Oct 16, 2005 at 11:48:40PM +0300, Timo Sirainen wrote:
On Sun, 2005-10-16 at 14:56 -0400, Glenn Leavell wrote:
dovecot: Oct 16 14:20:15 Error: imap(glenn): flock() locks not supported .. This looks like a locking issue on an index file. I had been leaving lock_method unset, letting it default to fcntl (inferred from the comments in dovecot-example.conf). I changed it to the explicit "lock_method = fcntl" and this fixed the problem.
Has the lock_method default changed from alpha3 to alpha4?
Yes. I forgot to mention this.
Thanks for the explanation. I'm now explicitly setting lock_method=fcntl in dovecot.conf, and that solved the problem, of course. However, one of my testers has been running a PREAUTH imap directly through an SSH tunnel (mutt supports this, for example). The command he's been running is:
/usr/local/libexec/dovecot/imapIt appears that the imap binary itself doesn't read the config file, so it was exiting with the same "flock()locks not supported" error. He was able to work around this by setting the LOCK_METHOD environment variable to the imap binary. But this means that he, as an end-user, needed to understand the behind-the-scenes locking situation in order to successfully run PREAUTH imap. In fact, he's been having to manually set the MAIL environment variable so that PREAUTH imap can find his INBOX (settings in dovecot.conf would normally help with this). Does it make sense for him to have to set these environment variables, or should PREAUTH imap read dovecot.conf for relevent settings?
Thanks, Glenn
-- Glenn Leavell glenn@usg.edu Office of Information and Instructional Technology Board of Regents of the University System of Georgia
On Wed, 2005-10-19 at 23:45 -0400, Glenn Leavell wrote:
Does it make sense for him to have to set these environment variables, or should PREAUTH imap read dovecot.conf for relevent settings?
"dovecot --exec-mail imap" reads the configuration file and executes the imap process. That's how it should be done. Although for some reason it doesn't seem to set MAIL environment right at least with me. Have to look at that..
Timo Sirainen tss@iki.fi writes:
On Wed, 2005-10-19 at 23:45 -0400, Glenn Leavell wrote:
Does it make sense for him to have to set these environment variables, or should PREAUTH imap read dovecot.conf for relevent settings?
"dovecot --exec-mail imap" reads the configuration file and executes the imap process. That's how it should be done. Although for some reason it doesn't seem to set MAIL environment right at least with me. Have to look at that..
This doesn't work at all for me (I'm the tester :) I get "PREAUTH" and the CAPABILITY string and then it dies as soon as I hit enter (whether or not I type an IMAP command). The end of the 'truss -f' output is below. It can't seem to find its pipes or socks.
25759: open("/usr/platform/SUNW,Sun-Fire-280R/lib/libc_psr.so.1", O_RDONLY) = 3 25759: mmap(0xFF3A0000, 8192, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0xFF3A0000 25759: close(3) = 0 25759: getustack(0xFFBFF35C) 25759: getrlimit(RLIMIT_STACK, 0xFFBFF354) = 0 25759: getcontext(0xFFBFF190) 25759: setustack(0xFF143A5C) 25759: sysconfig(_CONFIG_SEM_VALUE_MAX) = 2147483647 25759: getuid() = 115 [115] 25759: time() = 1129809582 25759: brk(0x000A5810) = 0 25759: brk(0x000AF810) = 0 25759: uname(0xFFBFF0F8) = 1 25759: getpid() = 25759 [25758] 25759: open64("/dev/urandom", O_RDONLY) = 3 25759: read(3, "C3EF IDC", 4) = 4 25759: fcntl(3, F_GETFD, 0x00000000) = 0 25759: fcntl(3, F_SETFD, 0x00000001) = 0 25759: brk(0x000AF810) = 0 25759: brk(0x000B1810) = 0 25759: sigaction(SIGINT, 0xFFBFF5C0, 0x00000000) = 0 25759: pipe() = 4 [5] 25759: fcntl(4, F_GETFD, 0x00000000) = 0 25759: fcntl(4, F_SETFD, 0x00000001) = 0 25759: fcntl(5, F_GETFD, 0x00000000) = 0 25759: fcntl(5, F_SETFD, 0x00000001) = 0 25759: sigaction(SIGTERM, 0xFFBFF5C0, 0x00000000) = 0 25759: sigaction(SIGPIPE, 0xFFBFF5C0, 0x00000000) = 0 25759: lstat64("/home/happy/Mail", 0xFFBFF4C8) = 0 25759: lstat64("/home/happy/Mail", 0xFFBFF4C8) = 0 25759: lstat64("/home/happy/Mail", 0xFFBFF4C8) = 0 25759: fcntl(0, F_GETFL, 0x00000000) = 2 25759: fcntl(0, F_SETFL, 0x00000082) = 0 25759: fcntl(1, F_GETFL, 0x00000000) = 130 25759: fcntl(1, F_SETFL, 0x00000082) = 0 25759: fstat64(0, 0xFFBFF550) = 0 25759: llseek(1, 0, SEEK_CUR) Err#29 ESPIPE 25759: getsockname(1, 0xFFBFF4D0, 0xFFBFF4CC, 1) = 0 25759: brk(0x000B1810) = 0 25759: brk(0x000B3810) = 0 25759: brk(0x000B3810) = 0 25759: brk(0x000B5810) = 0 25759: brk(0x000B5810) = 0 25759: brk(0x000B7810) = 0 25760: poll(0x0003B7C0, 2, 2147483647) = 1 25759: write(1, " * P R E A U T H [ C".., 146) = 146 25760: recv(5, " * P R E A U T H [ C".., 1024, 0) = 146 25760: write(1, " * P R E A U T H [ C".., 146) = 146 25760: write(4, " * O K [ R A W L O G".., 44) = 44 25760: write(4, " * P R E A U T H [ C".., 146) = 146 25760: poll(0x0003B7C0, 2, 2147483647) (sleeping...) 25759: poll(0x000AF228, 2, 9995) (sleeping...) 25759: poll(0x000AF228, 2, 9995) = 0 25759: poll(0x000AF228, 2, 0) = 0 25759: poll(0x000AF228, 2, 9999) (sleeping...) 25759: poll(0x000AF228, 2, 9999) = 0 25759: poll(0x000AF228, 2, 0) = 0 25760: poll(0x0003B7C0, 2, 2147483647) = 1 25760: recv(0, 0xFFBFF068, 1024, 0) Err#95 ENOTSOCK 25760: close(3) = 0 25760: close(4) = 0 25760: close(0) = 0 25760: close(1) = 0 25759: poll(0x000AF228, 2, 9999) = 1 25760: close(5) = 0 25759: read(0, 0x000B6278, 4096) = 0 25759: close(3) = 0 25759: close(4) = 0 25759: close(5) = 0 25760: _exit(0) 25759: _exit(0)
Mark Plaksin happy@usg.edu writes:
Timo Sirainen tss@iki.fi writes:
On Wed, 2005-10-19 at 23:45 -0400, Glenn Leavell wrote:
Does it make sense for him to have to set these environment variables, or should PREAUTH imap read dovecot.conf for relevent settings?
"dovecot --exec-mail imap" reads the configuration file and executes the imap process. That's how it should be done. Although for some reason it doesn't seem to set MAIL environment right at least with me. Have to look at that..
This doesn't work at all for me (I'm the tester :) I get "PREAUTH" and the CAPABILITY string and then it dies as soon as I hit enter (whether or not I type an IMAP command). The end of the 'truss -f' output is below. It can't seem to find its pipes or socks.
FWIW, the same thing happens if I run 'rawlog imap'. truss output looks the same.
Mark Plaksin happy@usg.edu writes:
Mark Plaksin happy@usg.edu writes:
Timo Sirainen tss@iki.fi writes:
On Wed, 2005-10-19 at 23:45 -0400, Glenn Leavell wrote:
Does it make sense for him to have to set these environment variables, or should PREAUTH imap read dovecot.conf for relevent settings?
"dovecot --exec-mail imap" reads the configuration file and executes the imap process. That's how it should be done. Although for some reason it doesn't seem to set MAIL environment right at least with me. Have to look at that..
This doesn't work at all for me (I'm the tester :) I get "PREAUTH" and the CAPABILITY string and then it dies as soon as I hit enter (whether or not I type an IMAP command). The end of the 'truss -f' output is below. It can't seem to find its pipes or socks.
FWIW, the same thing happens if I run 'rawlog imap'. truss output looks the same.
Actually, the problem *only* occurs if rawlog is involved. I just realized that in my initial --exec-mail test I was using a config file that specified the imap process as 'rawlog imap'. If I remove rawlog from the config file then --exec-mail works as expected.
I still can't get --exec-mail and rawlog to work together.
On Mon, 2005-10-24 at 11:49 -0400, Mark Plaksin wrote:
Actually, the problem *only* occurs if rawlog is involved. I just realized that in my initial --exec-mail test I was using a config file that specified the imap process as 'rawlog imap'. If I remove rawlog from the config file then --exec-mail works as expected.
Or you could also remove ~/dovecot.rawlog directory.
I still can't get --exec-mail and rawlog to work together.
They don't.. Fixed in CVS now.
Timo Sirainen wrote:
Please try if http://dovecot.org/nightly/dovecot-latest.tar.gz (or the CVS directly) works with you. I made a lot of changes to dovecot-auth,
Seems to run fine here (FC4 with gcc 4.0.1), though I didn't have any problems with alpha3 (running maildir here, seems to be more stable anyway), besides some inotify-related errors every now and then:
Oct 16 12:16:18 ymmv dovecot: imap(jh): inotify_rm_watch() failed: Invalid argument Oct 16 12:16:18 ymmv dovecot: imap(jh): inotify_rm_watch() failed: Invalid argument
btw, I don't know your priority regarding the lda, but the current cvs fails to compile:
bc_generate.c:37:19: error: sieve.h: No such file or directory bc_generate.c: In function 'bc_relation_generate': bc_generate.c:156: error: 'GT' undeclared (first use in this function) bc_generate.c:156: error: (Each undeclared identifier is reported only once bc_generate.c:156: error: for each function it appears in.) bc_generate.c:159: error: 'GE' undeclared (first use in this function) bc_generate.c:162: error: 'LT' undeclared (first use in this function) [...]
On 2005-10-17 10:51:48 +0200, Jakob Hirsch wrote:
btw, I don't know your priority regarding the lda, but the current cvs fails to compile:
bc_generate.c:37:19: error: sieve.h: No such file or directory bc_generate.c: In function 'bc_relation_generate': bc_generate.c:156: error: 'GT' undeclared (first use in this function) bc_generate.c:156: error: (Each undeclared identifier is reported only once bc_generate.c:156: error: for each function it appears in.) bc_generate.c:159: error: 'GE' undeclared (first use in this function) bc_generate.c:162: error: 'LT' undeclared (first use in this function) [...]
this should be solved already. please run cvs up and check if it still fails.
darix
Marcus Rueckert wrote:
btw, I don't know your priority regarding the lda, but the current cvs fails to compile:
bc_generate.c:37:19: error: sieve.h: No such file or directory this should be solved already. please run cvs up and check if it still fails.
Still fails. Even after deleting the dovecot-lda directory and doing a fresh checkout, there's no sieve.h.
On 2005-10-17 15:11:07 +0200, Jakob Hirsch wrote:
btw, I don't know your priority regarding the lda, but the current cvs fails to compile:
bc_generate.c:37:19: error: sieve.h: No such file or directory this should be solved already. please run cvs up and check if it still fails.
Still fails. Even after deleting the dovecot-lda directory and doing a fresh checkout, there's no sieve.h.
the file should be created.
seems timo forgot to move the sieve.y some lines higher. this patch [1] fixes it for me.
hope this helps
darixhttp://pixel.global-banlist.de/dovecot-lda_automakefixes.patch
participants (8)
-
Andrew Hutchings
-
Glenn Leavell
-
Jakob Hirsch
-
Johannes Berg
-
Marc Perkel
-
Marcus Rueckert
-
Mark Plaksin
-
Timo Sirainen