[Dovecot] v1.1.6 released
http://dovecot.org/releases/1.1/dovecot-1.1.6.tar.gz http://dovecot.org/releases/1.1/dovecot-1.1.6.tar.gz.sig
The invalid message address parsing bug is pretty important since it allows a remote user to send broken mail headers and prevent the recipient from accessing the mailbox afterwards, because the process will always just crash trying to parse the header. This is assuming that the IMAP client uses FETCH ENVELOPE command, not all do. Note that it doesn't affect versions older than v1.1.4.
+ dovecot -n and -a now prints some system information at the top.
+ More error/debug message logging improvements.
- pop3-login: Fixed assert-crash if a client sent USER+PASS+USER+PASS
commands in the same IP packet.
- Parsing an invalid message address like "From: (" caused an
assert-crash in v1.1.4 and v1.1.5.
- Folding whitespace wasn't handled correctly inside quoted-strings,
causing some messages to be parsed incorrectly.
- mbox: Fixed saving messages that begin with a valid From_-line.Timo Sirainen schreef:
http://dovecot.org/releases/1.1/dovecot-1.1.6.tar.gz http://dovecot.org/releases/1.1/dovecot-1.1.6.tar.gz.sig
I've refreshed the managesieve patch for the new Dovecot release.
http://www.rename-it.nl/dovecot/1.1/dovecot-1.1.6-managesieve-0.10.3.diff.gz http://www.rename-it.nl/dovecot/1.1/dovecot-1.1.6-managesieve-0.10.3.diff.gz...
Regards,
-- Stephan Bosch stephan@rename-it.nl
Has there been some issue fixed between 1.1.5 and 1.1.6 that could explain a huge drop in CPU use?
I was having problems with a 1.1.5 box that kept being on about 80% CPU (a dual quad core box). I updated it to 1.1.6, and ever since it's been at < 5% CPU. (no change in number of users).
Cor
On Nov 3, 2008, at 1:33 PM, Cor Bosman wrote:
Has there been some issue fixed between 1.1.5 and 1.1.6 that could
explain a huge drop in CPU use?I was having problems with a 1.1.5 box that kept being on about 80% CPU (a dual quad core box). I updated it to 1.1.6, and ever since it's been at < 5% CPU. (no change in number of users).
If there were no error messages logged with 1.1.5, there's nothing I
can think of that could explain it.
If there were no error messages logged with 1.1.5, there's nothing I
can think of that could explain it.
Im not sure when this started, but im seeing very high CPU use in dovecot. I recently swapped our systems to Linux from FreeBSD, and ive also moved versions up a few (now on 1.1.6).
Here's an idea of what im seeing:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
28554 xxx 20 0 11108 1452 1136 R 17 0.0 0:00.76 imap
28542 xxx 20 0 11004 1456 1120 R 16 0.0 0:00.86 imap
28552 xxx 20 0 11108 1504 1136 R 16 0.0 0:00.64 imap
28550 xxx 20 0 11168 1556 1176 R 15 0.0 0:00.78 imap
28485 xxx 20 0 11192 1588 1152 R 14 0.0 0:01.58 imap
24161 xxx 20 0 11124 1684 1204 R 13 0.0 0:20.44 imap
28521 xxx 20 0 13388 1816 1308 R 13 0.0 0:01.60 imap
28545 xxx 20 0 11108 1448 1136 R 13 0.0 0:00.82 imap
28486 xxx 20 0 11232 1612 1152 R 12 0.0 0:01.38 imap
28565 xxx 20 0 11268 1644 1148 R 12 0.0 0:00.56 imap
32470 xxx 20 0 15972 2428 1400 R 11 0.1 0:55.74 imap
28520 xxx 20 0 11152 1600 1212 R 11 0.0 0:01.10 imap
25056 xxx 20 0 13584 2072 1396 R 10 0.1 0:36.64 imap
25677 xxx 20 0 11108 1612 1172 R 10 0.0 0:09.22 imap
28347 xxx 20 0 11328 1708 1220 R 10 0.0 0:03.54 imap
At what stage does dovecot use a lot of CPU? What makes this more complicated is that im not seeing it on all servers. I currently have 35 in production and about 5 are showing this. A bit too many to be a server issue. Load is equally distributed so it's not that those 5 have more users on them.
Cor
On Tue, 2008-11-04 at 10:13 +0100, Cor Bosman wrote:
If there were no error messages logged with 1.1.5, there's nothing I
can think of that could explain it.Im not sure when this started, but im seeing very high CPU use in dovecot. I recently swapped our systems to Linux from FreeBSD, and ive also moved versions up a few (now on 1.1.6).
Here's an idea of what im seeing:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
28554 xxx 20 0 11108 1452 1136 R 17 0.0 0:00.76 imap
28542 xxx 20 0 11004 1456 1120 R 16 0.0 0:00.86 imap
Checking what the processes do would be helpful. Both strace (strace -p pid) and a couple of gdb backtraces (gdb -p pid, bt).
Actually, all CPU use is system , so it's a kernel thing, not a dovecot thing I guess.
Cor
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tue, 4 Nov 2008, Cor Bosman wrote:
Actually, all CPU use is system , so it's a kernel thing, not a dovecot thing I guess.
Do those machines swap?
Try to make a system trace (strace / truss)
However, the lifetime of most processes is just small. Maybe some users login and beat the machine, downloading every bit of the mail storage or permform lots of searches to sync with their local mail cache? I had one user using an old Thunderbird connecting only now and then, but had 5000+ mails in several folders; the sync made the machine almost unusable for others, because Thunderbird maintained about 6 (or so) connections, of which each tried to use one CPU 100%.
Bye.
Steffen Kaiser -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFJECS3VJMDrex4hCIRAsS8AKC64neBWl/euoSEImFihocAQpyE6ACglDzH K9EL1LUFV9CQdsZZgIZCuDI= =C9Wa -----END PGP SIGNATURE-----
Just wanted to mention that 1.1.6 seems fine so far in our testing, and I think the lack of reported problems on the mailing list is probably a very good sign!
Timo Sirainen wrote:
http://dovecot.org/releases/1.1/dovecot-1.1.6.tar.gz http://dovecot.org/releases/1.1/dovecot-1.1.6.tar.gz.sig
The invalid message address parsing bug is pretty important since it allows a remote user to send broken mail headers and prevent the recipient from accessing the mailbox afterwards, because the process will always just crash trying to parse the header. This is assuming that the IMAP client uses FETCH ENVELOPE command, not all do. Note that it doesn't affect versions older than v1.1.4.
- dovecot -n and -a now prints some system information at the top.
- More error/debug message logging improvements.
- pop3-login: Fixed assert-crash if a client sent USER+PASS+USER+PASS commands in the same IP packet.
- Parsing an invalid message address like "From: (" caused an assert-crash in v1.1.4 and v1.1.5.
- Folding whitespace wasn't handled correctly inside quoted-strings, causing some messages to be parsed incorrectly.
- mbox: Fixed saving messages that begin with a valid From_-line.
On Nov 19 2008, Adam McDougall wrote:
Just wanted to mention that 1.1.6 seems fine so far in our testing, and I think the lack of reported problems on the mailing list is probably a very good sign!
We're running 1.1.4 in production on one machine, and have tried 1.1.5. and 1.1.6 in our test environment... all three still sometimes have the "next message unexpectedly lost" error logged. This happens only for Outlook users, and corresponds to the user seeing a message with no subject or body in Outlook's list.
Other clients see the message fine. Effective workarounds:
- Delete index files.
- Have the user use a client such as Pine to "bounce" the message, or reply to it, or etc. After this Outlook can display it. We've sort of inferred that this is due to the fact that it's technically a "new" message now, as it is rewritten to add the appropriate header fields.
I sent in a bug report with dovecot -n output and etc a couple of weeks ago; that info still holds.
-Brian Hayden University of Minnesota
Timo Sirainen wrote:
http://dovecot.org/releases/1.1/dovecot-1.1.6.tar.gz http://dovecot.org/releases/1.1/dovecot-1.1.6.tar.gz.sig
The invalid message address parsing bug is pretty important since it allows a remote user to send broken mail headers and prevent the recipient from accessing the mailbox afterwards, because the process will always just crash trying to parse the header. This is assuming that the IMAP client uses FETCH ENVELOPE command, not all do. Note that it doesn't affect versions older than v1.1.4.
- dovecot -n and -a now prints some system information at the top.
- More error/debug message logging improvements.
- pop3-login: Fixed assert-crash if a client sent USER+PASS+USER+PASS commands in the same IP packet.
- Parsing an invalid message address like "From: (" caused an assert-crash in v1.1.4 and v1.1.5.
- Folding whitespace wasn't handled correctly inside quoted-strings, causing some messages to be parsed incorrectly.
- mbox: Fixed saving messages that begin with a valid From_-line.
-- Brian Hayden UMN OIT Internet Services
On Nov 19, 2008, at 10:29 PM, Brian Hayden wrote:
On Nov 19 2008, Adam McDougall wrote:
Just wanted to mention that 1.1.6 seems fine so far in our testing,
and I think the lack of reported problems on the mailing list is
probably a very good sign!We're running 1.1.4 in production on one machine, and have tried
1.1.5. and 1.1.6 in our test environment... all three still
sometimes have the "next message unexpectedly lost" error logged.
This happens only for Outlook users, and corresponds to the user
seeing a message with no subject or body in Outlook's list.
I've finally managed to reproduce this with my own mails a few days
ago. Now I'd just need to figure out what exactly is causing it and
fix it.
Other clients see the message fine. Effective workarounds:
- Delete index files.
- Have the user use a client such as Pine to "bounce" the message,
or reply to it, or etc. After this Outlook can display it. We've
sort of inferred that this is due to the fact that it's technically
a "new" message now, as it is rewritten to add the appropriate
header fields.
- Don't use mbox. :)
Although I thought this error was transparent to users. I get it every
few days and haven't really noticed any problems because of it. Wonder
what Outlook sees that causes it to break.
We're running 1.1.4 in production on one machine, and have tried 1.1.5. and 1.1.6 in our test environment... all three still sometimes have the "next message unexpectedly lost" error logged. This happens only for Outlook users, and corresponds to the user seeing a message with no subject or body in Outlook's list.
I've finally managed to reproduce this with my own mails a few days ago. Now I'd just need to figure out what exactly is causing it and fix it.
Glad you were able to identify the issue. We see it every few days as well using mbox and POP3 checking where sometimes an "in the middle" deletion of a message (via a POP3 checker POPTray) will cause the empty message to appear to any POP3 check with a pop checker, pegasus mail, outlook, etc... It does not appear to be isolated to Outlook. Deleting the index files resets things.
Other clients see the message fine. Effective workarounds:
- Delete index files.
- Have the user use a client such as Pine to "bounce" the message, or reply to it, or etc. After this Outlook can display it. We've sort of inferred that this is due to the fact that it's technically a "new" message now, as it is rewritten to add the appropriate header fields.
- Don't use mbox. :)
Although I thought this error was transparent to users. I get it every few days and haven't really noticed any problems because of it. Wonder what Outlook sees that causes it to break.
Haven't been able to pull the trigger on mbox -> maildir. As mentioned above, we see the empty message with any POP3 program, not just Outlook. Hopefully you narrow it down. If you need any more data, let me know, and we'll try and capture more the next time it happens.
Thanks.
Rob
We're running 1.1.4 in production on one machine, and have tried 1.1.5. and 1.1.6 in our test environment... all three still sometimes have the "next message unexpectedly lost" error logged. This happens only for Outlook users, and corresponds to the user seeing a message with no subject or body in Outlook's list.
I've finally managed to reproduce this with my own mails a few days ago. Now I'd just need to figure out what exactly is causing it and fix it.
Glad you were able to identify the issue. We see it every few days as well using mbox and POP3 checking where sometimes an "in the middle" deletion of a message (via a POP3 checker POPTray) will cause the empty message to appear to any POP3 check with a pop checker, pegasus mail, outlook, etc... It does not appear to be isolated to Outlook. Deleting the index files resets things.
As a followup, we just had this happen again on an mbox POP3 check. Using pine, the message appears normally. I used telnet to access the POP box through dovecot, issued a "RETR" command on the new message, and it was blank. then I issued a "RETR" command on the email before it, and again a RETR command on the "blank" email and it appeared normally from that point forward using dovecot.
Hope this helps in figuring out this issue.
Rob
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wed, 19 Nov 2008, Brian Hayden wrote:
1.1.6 in our test environment... all three still sometimes have the "next message unexpectedly lost" error logged. This happens only for Outlook users, and corresponds to the user seeing a message with no subject or body in Outlook's list.
Other clients see the message fine. Effective workarounds:
- Delete index files.
- Have the user use a client such as Pine to "bounce" the message, or reply to it, or etc. After this Outlook can display it. We've sort of inferred that this is due to the fact that it's technically a "new" message now, as it is rewritten to add the appropriate header fields.
Hmm, I have the same problem with Thunderbird and Dovecot v1.0.15 using Maildir now and then. The message is empty, no date/subject/whatsoever (it's the same if you put a non-readable file into Maildir). Thunderbird caches the empty info until I enter the IMAP folder with pine. Then the message data gets updated.
I didn't paid much attention to it, because I automatically move some messages from this folder into another one on file system level and assumed that this "empty" message is one of the mails that where moved in the same instant I accessed.
Now you mentioned it and I see such message again, I clicked "reget" several times with no luck, waited some minutes, again no luck. I entered the folder with Pine, the message got visible in Thunderbird. Funnily the mail is about 3 houres older than the first access to the mailbox today.
There is no entry in the logs.
Bye,
Steffen Kaiser -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFJJRs6VJMDrex4hCIRAj9/AKCtz+dzoa9suyC2Bueq9tlKfjPYmQCfe9hV ejDrS6r7F7Qh2sCnDCCjH0Y= =lnsd -----END PGP SIGNATURE-----
On Nov 20, 2008, at 10:09 AM, Steffen Kaiser wrote:
Hmm, I have the same problem with Thunderbird and Dovecot v1.0.15
using Maildir now and then. The message is empty, no date/subject/ whatsoever (it's the same if you put a non-readable file into
Maildir). Thunderbird caches the empty info until I enter the IMAP
folder with pine. Then the message data gets updated.
How are the new mails delivered to maildir?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Thu, 20 Nov 2008, Timo Sirainen wrote:
How are the new mails delivered to maildir?
With Dovecot's deliver, filtered by a Sieve script using "fileinto".
But moved away on filesystem level. It seems to be connected to folders, where message disapears, I have a SPAM folder, where I see the same behaviour now and then.
Bye,
Steffen Kaiser -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFJJUazVJMDrex4hCIRApPIAJ4sOUp70nHWVDbfXjFKNNqo1FnqLgCfXHHl JU5sNQC8RJPNmSUdxklYgyo= =Caon -----END PGP SIGNATURE-----
On Thu, 2008-11-20 at 12:14 +0100, Steffen Kaiser wrote:
On Thu, 20 Nov 2008, Timo Sirainen wrote:
How are the new mails delivered to maildir?
With Dovecot's deliver, filtered by a Sieve script using "fileinto".
But moved away on filesystem level. It seems to be connected to folders, where message disapears, I have a SPAM folder, where I see the same behaviour now and then.
Could you enable rawlog and see what Dovecot sends to Thunderbird when this problem happens?
I guess it's possible that this is the one v1.0 bug that I didn't bother fixing because I thought it was a too invasive change. It didn't have anything to do with moving messages though, simply that there's a small race condition where imap may see a new message as non-existing for a (really) short time after deliver has delivered it.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Fri, 21 Nov 2008, Timo Sirainen wrote:
Could you enable rawlog and see what Dovecot sends to Thunderbird when this problem happens?
Well, hunting something totally different I'm hit with this very problem on a test server. Attached you'll find the rawlogs of a session performing a type 1) case (see below).
The INBOX is completely empty, Thunderbird (aka Icedove 1.5.0.13+1.5.0.15b.dfsg1+prepatch080614d-0etch1 from Debian Etch) has selected Trash.
Then I perform (cross-device, "file" is unique through all cases):
- chown user file && mv file ~user/Maildir/new
"mv" tells me that it could not preserve the permissions etc. hence the file was seen (and moved to cur) before mv was finished.
- chown user file && mv file ~user/Maildir/tmp/file && mv ~user/Maildir/tmp/file ~user/Maildir/new/file
(no error)
As 2) but last mv replaced by: ln tmp/file new/file && rm tmp/file
As 3) but use cur subdir as target
In the end, the mails have no stats in the overview window (no subject, date, sender, ...), but I can pull the body successfully. Changes of "new" vs. "read" and the "flag" are preserved. Once the message is read, the message size is up to date. Thunderbird itself does not reload the message info (or invalidates local cache), neither with Get Mail nor Compact Mailbox. My Tbird version does not have no "rebuilt index" option in the properties tabs or context menu.
However, this happens on the production server with Dovecot deliver as LDA.
I guess it's possible that this is the one v1.0 bug that I didn't bother fixing because I thought it was a too invasive change. It didn't have anything to do with moving messages though, simply that there's a small race condition where imap may see a new message as non-existing for a (really) short time after deliver has delivered it.
For me personally I can live with this problem, as it seems that I'm the only victim of it here.
(I'm looking forward to v1.2's shared users mailboxes anyway.)
=== Below are the server confs:
./sbin/dovecot --build-options Build options: ioloop=epoll notify=inotify ipv6 openssl SQL drivers: postgresql Passdb: checkpassword ldap pam passwd passwd-file shadow sql Userdb: checkpassword ldap passwd prefetch passwd-file sql static
====
# 1.0.15: /usr/local/dovecot-1.0.15patch4mgtsv92epoll/etc/dovecot.conf base_dir: /var/run/dovecot/ log_path: /var/log/dovecot/dovecot.log log_timestamp: %F %H:%M:%S protocols: imap imaps pop3 pop3s managesieve listen(default): * listen(imap): * listen(pop3): * listen(managesieve): *:2000 ssl_ca_file: /etc/ssl/certs/ca.crt ssl_cert_file(default): /etc/ssl/certs/imap.pem ssl_cert_file(imap): /etc/ssl/certs/imap.pem ssl_cert_file(pop3): /etc/ssl/certs/pop3.pem ssl_cert_file(managesieve): /etc/ssl/certs/imap.pem ssl_key_file(default): /etc/ssl/private/imap.key ssl_key_file(imap): /etc/ssl/private/imap.key ssl_key_file(pop3): /etc/ssl/private/pop3.key ssl_key_file(managesieve): /etc/ssl/private/imap.key disable_plaintext_auth: no verbose_ssl: yes login_dir(default): /var/run/dovecot//login login_dir(imap): /var/run/dovecot//login login_dir(pop3): /var/run/dovecot//login login_dir(managesieve): /var/run/dovecot/login login_executable(default): /usr/local/dovecot-1.0.15patch4mgtsv92epoll/libexec/dovecot/imap-login login_executable(imap): /usr/local/dovecot-1.0.15patch4mgtsv92epoll/libexec/dovecot/imap-login login_executable(pop3): /usr/local/dovecot-1.0.15patch4mgtsv92epoll/libexec/dovecot/pop3-login login_executable(managesieve): /usr/local/dovecot-1.0.15patch4mgtsv92epoll/libexec/dovecot/managesieve-login login_log_format_elements: %p: user=<%u> method=%m rip=%r lip=%l %c login_processes_count: 10 login_max_processes_count: 256 verbose_proctitle: yes first_valid_uid: 10 mail_location(default): maildir:%h/Maildir:CONTROL=/var/cache/dovecot/%i/control:INDEX=/var/cache/dovecot/%i/index mail_location(imap): maildir:%h/Maildir:CONTROL=/var/cache/dovecot/%i/control:INDEX=/var/cache/dovecot/%i/index mail_location(pop3): maildir:%h/Maildir:CONTROL=/var/cache/dovecot/%i/control:INDEX=/var/cache/dovecot/%i/index mail_location(managesieve): maildir:%h/Maildir mail_debug: yes dotlock_use_excl: yes maildir_copy_with_hardlinks: yes maildir_copy_preserve_filename: yes umask: 7 mail_executable(default): /usr/local/dovecot-1.0.15patch4mgtsv92epoll/libexec/dovecot/rawlog /usr/local/dovecot-1.0.15patch4mgtsv92epoll/libexec/dovecot/imap mail_executable(imap): /usr/local/dovecot-1.0.15patch4mgtsv92epoll/libexec/dovecot/rawlog /usr/local/dovecot-1.0.15patch4mgtsv92epoll/libexec/dovecot/imap mail_executable(pop3): /usr/local/dovecot-1.0.15patch4mgtsv92epoll/libexec/dovecot/pop3 mail_executable(managesieve): /usr/local/dovecot-1.0.15patch4mgtsv92epoll/libexec/dovecot/managesieve mail_plugins(default): quota imap_quota mail_log antispam mail_plugins(imap): quota imap_quota mail_log antispam mail_plugins(pop3): quota mail_log mail_plugins(managesieve): mail_plugin_dir(default): /usr/local/dovecot-1.0.15patch4mgtsv92epoll/lib/dovecot/imap mail_plugin_dir(imap): /usr/local/dovecot-1.0.15patch4mgtsv92epoll/lib/dovecot/imap mail_plugin_dir(pop3): /usr/local/dovecot-1.0.15patch4mgtsv92epoll/lib/dovecot/pop3 mail_plugin_dir(managesieve): /usr/local/dovecot-1.0.15patch4mgtsv92epoll/lib/dovecot/managesieve mail_log_prefix: %Us(%u) [%p]: mail_log_max_lines_per_sec: 0 pop3_uidl_format(default): pop3_uidl_format(imap): pop3_uidl_format(pop3): %08Xu%08Xv pop3_uidl_format(managesieve): pop3_client_workarounds(default): pop3_client_workarounds(imap): pop3_client_workarounds(pop3): oe-ns-eoh pop3_client_workarounds(managesieve): namespace: type: private separator: . inbox: yes auth default: mechanisms: plain login cache_size: 10 username_chars: [snip] verbose: yes debug: yes passdb: driver: passwd-file args: /etc/user.deny deny: yes passdb: driver: ldap args: /usr/local/dovecot-1.0.15patch4mgtsv92epoll/etc/dovecot-ldap.conf userdb: driver: ldap args: /usr/local/dovecot-1.0.15patch4mgtsv92epoll/etc/dovecot-ldap.conf userdb: driver: passwd socket: type: listen master: path: /var/run/dovecot/auth-master mode: 432 group: mail plugin: quota: fs antispam_trash: [snip] antispam_spam: [snip] antispam_mail_sendmail: /bin/false antispam_mail_sendmail_args: %u antispam_mail_tmpdir: /tmp/spamspool antispam_allow_append_to_spam: yes
Bye,
Steffen Kaiser -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFJSQxGVJMDrex4hCIRApdJAKCZMB6djYr/KFJ3BQEw248th4fFnwCguuFi p38CRb0OD+aIdvjy+zmq3o0= =/i67 -----END PGP SIGNATURE-----
On Dec 17, 2008, at 4:27 PM, Steffen Kaiser wrote:
Then I perform (cross-device, "file" is unique through all cases):
- chown user file && mv file ~user/Maildir/new
You mean the source and destination are on different filesystems? Then
this is more or less expected, because then "mv" isn't an atomic
operation. Dovecot sees and reads the message before mv has finished
writing it. That's the point of having the tmp/ directory. Mails
should be written there first, then atomically renamed to new/.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wed, 17 Dec 2008, Timo Sirainen wrote:
- chown user file && mv file ~user/Maildir/new
You mean the source and destination are on different filesystems? Then this is more or less expected, because then "mv" isn't an atomic operation. Dovecot sees and reads the message before mv has finished writing it. That's the point of having the tmp/ directory. Mails should be written there first, then atomically renamed to new/.
Yes, therefore I tested the other cases, too, where the mail is written to tmp first.
Bye,
Steffen Kaiser -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFJSQ7hVJMDrex4hCIRAqaNAKCKyrEcPW85SDfaG9yPtfZykcnd4gCgh6NO 6U/LNINHUzfoogMzaCAVdvw= =5Nsb -----END PGP SIGNATURE-----
On Dec 17, 2008, at 4:38 PM, Steffen Kaiser wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wed, 17 Dec 2008, Timo Sirainen wrote:
- chown user file && mv file ~user/Maildir/new
You mean the source and destination are on different filesystems?
Then this is more or less expected, because then "mv" isn't an
atomic operation. Dovecot sees and reads the message before mv has finished writing
it. That's the point of having the tmp/ directory. Mails should be
written there first, then atomically renamed to new/.Yes, therefore I tested the other cases, too, where the mail is
written to tmp first.
Then I didn't really understand your mail. You could reproduce the
error with all 1) to 4) cases? But the rawlogs were only from the 1)
case? Why not from a case that wasn't supposed to have been broken? :)
I see this from time to time too. But if right click on the folder in thunderbird, select properties from the context menu, and hit rebuild index in the properties dialog, it fixes it. It crops up for me several times a day.
I'm still back at 1.1.rc1 though.
John
Steffen Kaiser wrote:
On Wed, 19 Nov 2008, Brian Hayden wrote:
1.1.6 in our test environment... all three still sometimes have the "next message unexpectedly lost" error logged. This happens only for Outlook users, and corresponds to the user seeing a message with no subject or body in Outlook's list.
Other clients see the message fine. Effective workarounds:
- Delete index files.
- Have the user use a client such as Pine to "bounce" the message, or reply to it, or etc. After this Outlook can display it. We've sort of inferred that this is due to the fact that it's technically a "new" message now, as it is rewritten to add the appropriate header fields.
Hmm, I have the same problem with Thunderbird and Dovecot v1.0.15 using Maildir now and then. The message is empty, no date/subject/whatsoever (it's the same if you put a non-readable file into Maildir). Thunderbird caches the empty info until I enter the IMAP folder with pine. Then the message data gets updated.
I didn't paid much attention to it, because I automatically move some messages from this folder into another one on file system level and assumed that this "empty" message is one of the mails that where moved in the same instant I accessed.
Now you mentioned it and I see such message again, I clicked "reget" several times with no luck, waited some minutes, again no luck. I entered the folder with Pine, the message got visible in Thunderbird. Funnily the mail is about 3 houres older than the first access to the mailbox today.
There is no entry in the logs.
Bye,
-- Steffen Kaiser
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Thu, 20 Nov 2008, John Gray wrote:
I see this from time to time too. But if right click on the folder in thunderbird, select properties from the context menu, and hit rebuild index in the properties dialog, it fixes it. It crops up for me several
Ah, cool! It works. It's named "Offline | Download now" in my revision of Thunderbird. I just clicked the "get messages" button with no luck, as well as switching folders. So propably it's a caching problem only?
Because I usually use Alpine, I do not see the problem often, however, some tasks are pain in Pine.
Bye,
Steffen Kaiser -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFJJnqSVJMDrex4hCIRAhsjAKCyEhb50Q8l6kiwtQ2ksUVu+ySjggCgxaM9 u0pC8kNNYeCJ3nj0FH82Rus= =Htel -----END PGP SIGNATURE-----
On 11/21/2008 4:08 AM, Steffen Kaiser wrote:
On Thu, 20 Nov 2008, John Gray wrote:
I see this from time to time too. But if right click on the folder in thunderbird, select properties from the context menu, and hit rebuild index in the properties dialog, it fixes it. It crops up for me several
Ah, cool! It works. It's named "Offline | Download now" in my revision of Thunderbird. I just clicked the "get messages" button with no luck, as well as switching folders. So propably it's a caching problem only?
? weird...
In my Thunderbird, the only way to get to the 'Rebuild Index' function/button is:
right-click a folder > 'Properties' > 'General Information' tab
Did you try to simply right-click a folder and click 'Compact'? Maybe that will work too, as I would think it would also have to rebuild the index.
--
Best regards,
Charles
On Wednesday, November 19 at 10:56 AM, quoth Adam McDougall:
Just wanted to mention that 1.1.6 seems fine so far in our testing, and I think the lack of reported problems on the mailing list is probably a very good sign!
For whatever reason, we ran into the "userdb didn't return a home directory" problem with 1.1.6, and quickly downgraded back to 1.1.5. http://thread.gmane.org/gmane.mail.imap.dovecot/34008/focus=34009
It's rather silly too, since the userdb *does* return a home directory (which is why I'm skeptical of the "fix" mentioned there that forces a default home directory of /tmp). Here's hoping 1.1.7 (whenever it comes out) is a smoother upgrade.
~Kyle
History will be kind to me, for I intend to write it. -- Winston Churchill
participants (10)
-
Adam McDougall
-
Brian Hayden
-
Charles Marcus
-
Cor Bosman
-
John Gray
-
Kyle Wheeler
-
Rob Mangiafico
-
Steffen Kaiser
-
Stephan Bosch
-
Timo Sirainen