[Dovecot] Running dovecot master processes across multiple IPs
We are running dovecot 1.1.8 and are currently running it with 4 master processes (one for each of the protocols: imap, imaps, pop3, pop3s). The idea was to spread out the load so as to not overwhelm any one master. This has worked well. To take it further, we're contemplating running masters across multiple IP addresses, where the host/service name DNS records would be something like this: imap-server.domain A 10.1.1.1 A 10.1.1.2 A 10.1.1.3 A 10.1.1.4 The default route would either be through the first address (10.1.1.1 in this example) or potentially across all of them in presumably a round-robin fashion. Do you see any problems with this? Has anyone done this? -- Steven F. Siirila Office: WBOB, 624J Internet Services E-mail: s...@umn.edu Office of Information TechnologyVoice: (612) 626-0244 University of Minnesota
[Dovecot] Dovecot master process
We are running into a situation where Dovecot master is simply trying to do too much. It some situations, we are finding that there are times in which it cannot service requests. Restarting Dovecot seems to help in these situations, possibly due to the fact that it no longer has to manage its THOUSANDS of file descriptors for pipes to the many imap/proxy processes that it uses for logging. Is there a way to turn off logging through the master process (in exchange for lesser security)? If not, would it be easy to have the master process do its logging using separate threads (which would help on some modern hardware)? Finally, would it be easy to delegate the task of logging to a dedicated process? We are still running Dovecot 1.0.0 at this time, on Solaris 10 servers. -- Steven F. Siirila Office: WBOB, 621F Internet Services E-mail: [EMAIL PROTECTED] Office of Information TechnologyVoice: (612) 626-0244 University of Minnesota Fax: (612) 626-7593
Re: [Dovecot] graceful failure when some folders are not available...
Did I miss a reply on this? We're considering modifying Dovecot, but would like opinions before going down the wrong path... On Mon, Oct 08, 2007 at 04:39:25PM -0500, Steven F Siirila wrote: On Sat, Oct 06, 2007 at 04:28:20AM +0300, Timo Sirainen wrote: On Wed, 2007-10-03 at 20:03 -0500, [EMAIL PROTECTED] wrote: Hi folks. Quick question in the hopes that someone knows the answer, before I dig in the code some more. In testing a new setup with some long-term archival mbox-format mailboxes stored on an NFS mount, we've found the following: if the mount is unavailable for any reason, the user cannot log into their email at all. Dovecot says: stat() failed with mbox foo and dies. This is coming from Perhaps dies was too strong. In fact, Dovecot does not die, but the client perceives such as it is told this upon trying to log in: The current command did not succeed. The mail server responded: Internal error occurred. Refer to server log for more information. And in fact your tests (below) reproduced this. The problem with this is that if even one file or directory within the user's IMAP folder space is currently unavailable (due to an NFS server being down), the user cannot log in at all to access any of their other folders. In out scenario, we would prefer that the user simply not see the folders (treat the error the same as file not found). BTW, the errno seen is ETIMEDOUT (we are soft mounting the NFS filesystem in question). Any thoughts on how we can accomplish this? We don't normally expect this NFS filesystem to become unavailable, but when it is, we don't want it to prevent all users from being able to log in, since this NFS filesystem only holds folders of an archival nature. the mbox sync checks. (It's possible the same happens with a maildir folder--I'm just specifying mbox because that's what we've tested with so far). It shouldn't die. Maybe your client kills the connection? I tested this by making the stat() call always fail with EIO: x select inbox x NO Internal error occurred. Refer to server log for more information. [2007-10-06 04:24:48] x status foo (messages) x NO Internal error occurred. Refer to server log for more information. [2007-10-06 04:24:58] Or even if the mailbox is successfully opened and after that: x noop * NO Internal error occurred. Refer to server log for more information. [2007-10-06 04:27:31] x OK NOOP completed. -- Steven F. Siirila Office: Univ Park Plaza, Room 750 Internet Services E-mail: [EMAIL PROTECTED] Office of Information Technology Voice: (612) 626-0244 University of Minnesota Fax: (612) 626-7593 -- Steven F. Siirila Office: Univ Park Plaza, Room 750 Internet Services E-mail: [EMAIL PROTECTED] Office of Information TechnologyVoice: (612) 626-0244 University of Minnesota Fax: (612) 626-7593
Re: [Dovecot] graceful failure when some folders are not available...
On Sat, Oct 06, 2007 at 04:28:20AM +0300, Timo Sirainen wrote: On Wed, 2007-10-03 at 20:03 -0500, [EMAIL PROTECTED] wrote: Hi folks. Quick question in the hopes that someone knows the answer, before I dig in the code some more. In testing a new setup with some long-term archival mbox-format mailboxes stored on an NFS mount, we've found the following: if the mount is unavailable for any reason, the user cannot log into their email at all. Dovecot says: stat() failed with mbox foo and dies. This is coming from Perhaps dies was too strong. In fact, Dovecot does not die, but the client perceives such as it is told this upon trying to log in: The current command did not succeed. The mail server responded: Internal error occurred. Refer to server log for more information. And in fact your tests (below) reproduced this. The problem with this is that if even one file or directory within the user's IMAP folder space is currently unavailable (due to an NFS server being down), the user cannot log in at all to access any of their other folders. In out scenario, we would prefer that the user simply not see the folders (treat the error the same as file not found). BTW, the errno seen is ETIMEDOUT (we are soft mounting the NFS filesystem in question). Any thoughts on how we can accomplish this? We don't normally expect this NFS filesystem to become unavailable, but when it is, we don't want it to prevent all users from being able to log in, since this NFS filesystem only holds folders of an archival nature. the mbox sync checks. (It's possible the same happens with a maildir folder--I'm just specifying mbox because that's what we've tested with so far). It shouldn't die. Maybe your client kills the connection? I tested this by making the stat() call always fail with EIO: x select inbox x NO Internal error occurred. Refer to server log for more information. [2007-10-06 04:24:48] x status foo (messages) x NO Internal error occurred. Refer to server log for more information. [2007-10-06 04:24:58] Or even if the mailbox is successfully opened and after that: x noop * NO Internal error occurred. Refer to server log for more information. [2007-10-06 04:27:31] x OK NOOP completed. -- Steven F. Siirila Office: Univ Park Plaza, Room 750 Internet Services E-mail: [EMAIL PROTECTED] Office of Information TechnologyVoice: (612) 626-0244 University of Minnesota Fax: (612) 626-7593
Re: [Dovecot] Dovecot LDA munging INBOX access times?
On Sun, Jun 17, 2007 at 01:24:46PM +0300, Timo Sirainen wrote: On Fri, 2007-06-15 at 14:07 -0500, Steven F Siirila wrote: Hmm. I wonder how much of a timing window is left; this could be a viable option for us. However, I would like to consider our future options for mailbox formats other than mbox (we will eventually migrate I'm sure). For the mbox case (our immediate concern) your patch seems perfect, provided that it is performing the read of the access time and the re-setting of the access time during the time that the INBOX is locked. Timo, is this the case? That's right. Great! Will you be incorporating this patch into a future release? (Right now we have incorporated it as a local mod.) What we are considering doing is updating our local mailattrd to lock using the same mechanism Dovecot is before reading the access time: lock /var/mail/user (open RDONLY, fcntl SETLKW) stat /var/mail/user (to get last access time) unlock /var/mail/user (close) Unfortunately, it is more overhead. But it should be 100% accurate. That should work. Or I guess you saw my other mail already too? That doesn't require creating the lock, but should be 100% accurate as well. Since there is no way to check the lock for fcntl locks, I think we're left with no choice but to use the above code. Thanks again! -- Steven F. Siirila Office: Lind Hall, Room 130B Internet Services E-mail: [EMAIL PROTECTED] Office of Information TechnologyVoice: (612) 626-0244 University of Minnesota Fax: (612) 626-7593
Re: [Dovecot] Dovecot LDA munging INBOX access times?
OK, I have some more sane thoughts after we discussed our local situation. See inline comments. On Wed, Jun 13, 2007 at 10:51:02PM -0500, Steven F Siirila wrote: On Thu, Jun 14, 2007 at 06:22:45AM +0300, Timo Sirainen wrote: On Wed, 2007-06-13 at 17:52 -0500, Steven F Siirila wrote: We are running Dovecot 1.0.0 using mbox format (currently in the midst of conversion from UW IMAP). We discovered today that the Dovecot LDA is accessing the user's INBOX at delivery time! Well, there are two things: 1) It always makes sure that the mbox file ends with \n. I guess this isn't all that important, but I'm not really interested in just removing the code. If that were the only reason for opening in read mode I'd lobby for this to be changed. :) 2) If index files are fully synced, Dovecot writes X-UID: header. It also updates nextuid field in X-IMAP: / X-IMAPbase: header of the first message, which causes Dovecot to read() the file. The nextuid update isn't really required, but I think some other bug shows up if it isn't done. Do these operations apply to Deliver or just IMAP/POP? Not knowing enough about how the indexes work Question: Is it possible for Deliver to append a message w/o writing an X-UID header, leaving that operation to the IMAP/POP client code, and still maintain an updated index? This is still an open question, but not as important to be answered now. If not, are there any options I can provide to Dovecot LDA to make it function without index file updating? To answer my own question, one could probably use a very large value for 'mbox_min_index_size'. It would be possible to check the atime before any reading is done and then later after message is saved it could be updated back. Hmm. Well, attached a patch that seems to work. I'm not sure if I want to add it to v1.0.1. Hmm. I wonder how much of a timing window is left; this could be a viable option for us. However, I would like to consider our future options for mailbox formats other than mbox (we will eventually migrate I'm sure). For the mbox case (our immediate concern) your patch seems perfect, provided that it is performing the read of the access time and the re-setting of the access time during the time that the INBOX is locked. Timo, is this the case? What we have is a daemon called mailattrd on our mail servers which runs on a TCP port and simply does a stat() on a user's mailbox and returns the atime, mtime, ctime values of said mailbox. That service is used by a variety of our applications. We were thinking of another possibility: changing Dovecot IMAP/POP to update the last access time (open in READ) of a specific file other than the user's INBOX. However, we'd rather not maintain local modifications unless absolutely necessary. Any thoughts on alternatives which might be mailbox-format-independent? What we are considering doing is updating our local mailattrd to lock using the same mechanism Dovecot is before reading the access time: lock /var/mail/user (open RDONLY, fcntl SETLKW) stat /var/mail/user (to get last access time) unlock /var/mail/user (close) Unfortunately, it is more overhead. But it should be 100% accurate. This should give us an accurate last time the user accessed their INBOX. I'm not sure how this would work with other mailbox formats, but we'll cross that bridge when we get there. Thanks Timo for your super and timely support -- it is greatly appreciated!! -- Steven F. Siirila Office: Lind Hall, Room 130B Internet Services E-mail: [EMAIL PROTECTED] Office of Information TechnologyVoice: (612) 626-0244 University of Minnesota Fax: (612) 626-7593
Re: [Dovecot] Dovecot LDA munging INBOX access times?
On Wed, Jun 13, 2007 at 08:30:52PM -0400, John Peacock wrote: Steven F Siirila wrote: We are running Dovecot 1.0.0 using mbox format (currently in the midst of conversion from UW IMAP). We discovered today that the Dovecot LDA is accessing the user's INBOX at delivery time! Umm, yeah, that's kind of the point. mbox format is one big file with all of the messages concatenated together. So if a new message is delivered, then the INBOX file has to be opened to append the new message. Opened as WRITE ONLY APPEND. That doesn't update last access time. This isn't a bug by any stretch, but rather a different operational method than what you were expecting. I'm not claiming this is a bug, it is a major issue for us though. I'm guessing that UW IMAP doesn't retrieve new messages until the user asks for them (e.g. out of /var/mail/something). If you are using deliver, it actually, you know, _delivers_ the message. I think that there is a way to have the same behavior as UW IMAP, but I don't know off the top of my head how to do that (since we use maildir instead). It isn't the UW IMAP behavior, it is the former MTA's deliver behavior that is the issue. Most MTAs (actually MDAs) simply append to the inbox, which does not update the last access time. You may want to check the list archives first, rather than claiming dovecot is doing something wrong... Again, I'm not making such a claim. I have a problem that needs resolution, and I seek input from others who may have run into this same issue in the past. John -- John Peacock Director of Information Research and Technology Rowman Littlefield Publishing Group 4501 Forbes Blvd Suite H Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5747 -- Steven F. Siirila Office: Lind Hall, Room 130B Internet Services E-mail: [EMAIL PROTECTED] Office of Information TechnologyVoice: (612) 626-0244 University of Minnesota Fax: (612) 626-7593
Re: [Dovecot] Dovecot LDA munging INBOX access times?
On Thu, Jun 14, 2007 at 06:22:45AM +0300, Timo Sirainen wrote: On Wed, 2007-06-13 at 17:52 -0500, Steven F Siirila wrote: We are running Dovecot 1.0.0 using mbox format (currently in the midst of conversion from UW IMAP). We discovered today that the Dovecot LDA is accessing the user's INBOX at delivery time! Well, there are two things: 1) It always makes sure that the mbox file ends with \n. I guess this isn't all that important, but I'm not really interested in just removing the code. If that were the only reason for opening in read mode I'd lobby for this to be changed. :) 2) If index files are fully synced, Dovecot writes X-UID: header. It also updates nextuid field in X-IMAP: / X-IMAPbase: header of the first message, which causes Dovecot to read() the file. The nextuid update isn't really required, but I think some other bug shows up if it isn't done. Do these operations apply to Deliver or just IMAP/POP? Not knowing enough about how the indexes work Question: Is it possible for Deliver to append a message w/o writing an X-UID header, leaving that operation to the IMAP/POP client code, and still maintain an updated index? If not, are there any options I can provide to Dovecot LDA to make it function without index file updating? It would be possible to check the atime before any reading is done and then later after message is saved it could be updated back. Hmm. Well, attached a patch that seems to work. I'm not sure if I want to add it to v1.0.1. Hmm. I wonder how much of a timing window is left; this could be a viable option for us. However, I would like to consider our future options for mailbox formats other than mbox (we will eventually migrate I'm sure). What we have is a daemon called mailattrd on our mail servers which runs on a TCP port and simply does a stat() on a user's mailbox and returns the atime, mtime, ctime values of said mailbox. That service is used by a variety of our applications. We were thinking of another possibility: changing Dovecot IMAP/POP to update the last access time (open in READ) of a specific file other than the user's INBOX. However, we'd rather not maintain local modifications unless absolutely necessary. Any thoughts on alternatives which might be mailbox-format-independent? Thanks Timo for your super and timely support -- it is greatly appreciated!! -- Steven F. Siirila Office: Lind Hall, Room 130B Internet Services E-mail: [EMAIL PROTECTED] Office of Information TechnologyVoice: (612) 626-0244 University of Minnesota Fax: (612) 626-7593
Re: [Dovecot] message-of-the-day feature?
On Sun, Apr 22, 2007 at 06:41:28PM -0500, Ethan Sommer wrote: Steven F Siirila wrote: On Thu, Apr 19, 2007 at 06:22:05PM +0200, Jakob Hirsch wrote: Quoting Odhiambo WASHINGTON: You can do just that with dovecot, see http://wiki.dovecot.org/PostLoginScripting It's not very good performance-wise, because you spawn extra processes for each login, but it depends on your setup/use-case how much it affects you. That's worth noting, but... What about getting notices out to those folks whose IMAP client stays connected (sometimes for days on end)? You could always kill all their connections. Most clients will reconnect and in an emergency I'd imagine it would outweigh any inconvenience to your users. Good point, although it would still be nice to have something integrated into Dovecot to handle alert messages. Ethan -- -- Ethan Sommer Systems Administrator Gustavus Adolphus College 507-933-7042 [EMAIL PROTECTED] -- Steven F. Siirila Office: Lind Hall, Room 130B Internet Services E-mail: [EMAIL PROTECTED] Office of Information TechnologyVoice: (612) 626-0244 University of Minnesota Fax: (612) 626-7593
[Dovecot] message-of-the-day feature?
For lack of a better name, we are interested in a feature where one could get a notice out to all Dovecot users as quickly as possible, possibly without going through an MTA even. Given a message and a list of userids we could certainly do a mailing on the MDA server itself going through both Postfix and Dovecot LDA. However, we were wondering what other options we might have in Dovecot. For example, would it be possible to place the message into some file which Dovecot periodically checks for, and if the file exists, either present it to the user as a new message, or automatically deliver it at that time via Dovecot LDA? -- Steven F. Siirila Office: Lind Hall, Room 130B Internet Services E-mail: [EMAIL PROTECTED] Office of Information TechnologyVoice: (612) 626-0244 University of Minnesota Fax: (612) 626-7593
Re: [Dovecot] Released 1.0.rc31
On Sun, Apr 08, 2007 at 12:16:08PM +0300, Timo Sirainen wrote: http://dovecot.org/releases/dovecot-1.0.rc31.tar.gz http://dovecot.org/releases/dovecot-1.0.rc31.tar.gz.sig mbox + NFS combination shouldn't break anymore. v1.0 still planned to be released next friday. - mbox: Give mbox file was modified while we were syncing error only if we detect some problems in the mbox file. The check can't be trusted with NFS. - Convert plugin: If directory for destination storage doesn't exist, create it. - Convert plugin: Mailbox names weren't converted in subscription list. RC31 is screaming for version 1 to be released: 31 == 1 binary. :) -- Steven F. Siirila Office: Lind Hall, Room 130B Internet Services E-mail: [EMAIL PROTECTED] Office of Information TechnologyVoice: (612) 626-0244 University of Minnesota Fax: (612) 626-7593
Re: [Dovecot] odd behavior with Dovecot LDA
On Tue, Mar 27, 2007 at 11:02:28PM +0300, Timo Sirainen wrote: . . . On 27.3.2007, at 22.40, Steven F Siirila wrote: For the second test, I created $HOME/.imap and $HOME/.imap/INBOX directories with the owner and group set to that of the user (just to make sure the code handled things the same). Again, I received the vacation message, but the message which was supposed to be delivered locally bounced back to me after Dovecot LDA crashed: [EMAIL PROTECTED]: Command died with status 139: /opt/ dovecot/libexec/dovecot/deliver -f $SENDER. Command output: Segmentation Fault Could you get gdb backtrace? Although it's possible that it's already fixed. I can't reproduce any out-of-quota problems with current CVS code. (gdb) bt #0 mail_cache_register_fields (cache=0x0, fields=0xbfd90, fields_count=9) at mail-cache-fields.c:72 #1 0x00045fc4 in index_storage_mailbox_init (ibox=0xbf9a8, name=0xbfd90 , flags=12, move_to_memory=false) at index-storage.c:254 #2 0x0002ad70 in mbox_alloc (storage=0xae5e0, index=0xc23e0, name=0x83408 INBOX, path=0xae678 /var/mail/syst0006, flags=12) at mbox-storage.c:561 #3 0x0002af00 in mbox_open (storage=0xae5e0, name=0x83408 INBOX, flags=12) at mbox-storage.c:677 #4 0x0002b11c in mbox_mailbox_open (_storage=0xae5e0, name=0x80588 INBOX, input=0x0, flags=12) at mbox-storage.c:788 #5 0x00060134 in mailbox_open (storage=0xae5e0, name=0x80588 INBOX, input=0x0, flags=12) at mail-storage.c:365 #6 0x0001d630 in deliver_save (storage=0xae5e0, mailbox=0x80588 INBOX, mail=0xbec38, flags=0, keywords=0x0) at deliver.c:84 #7 0x0001e57c in main (argc=669592, argv=0xa3810) at deliver.c:677 -- Steven F. Siirila Office: Lind Hall, Room 130B Internet Services E-mail: [EMAIL PROTECTED] Office of Information TechnologyVoice: (612) 626-0244 University of Minnesota Fax: (612) 626-7593
Re: [Dovecot] assertion failed (1.0-rc27)
On Wed, Mar 28, 2007 at 10:24:40PM +0300, Timo Sirainen wrote: On 28.3.2007, at 22.13, Steven F Siirila wrote: Under Dovecot 1.0-rc27 on Solaris 10 we noticed this error today affecting one of our users repeatedly: Mar 28 14:02:01 myhost dovecot: IMAP(myuser): file mbox-sync- rewrite.c: line 423 (mbox_sync_read_and_move): assertion failed: (need_space == (uoff_t)-mails[idx].space) In rc28 I've changed this assert to something that prints more useful information. This assert alone doesn't really tell anything what the problem could have been. Anyway if it happened repeatedly, it would be nice to get the anonymized mbox and index files. See http://wiki.dovecot.org/ MboxProblems I have reproduced this on a test box; here is the backtrace from the core that was generated: #0 0xff1c16e8 in _sys_siginfolist_data () from /lib/libc.so.1 #1 0xff15ff40 in __strxfrm_std () from /lib/libc.so.1 #2 0xff140160 in getutxline () from /lib/libc.so.1 #3 0x0007b1b8 in i_internal_panic_handler ( fmt=0x929c8 file %s: line %d (%s): assertion failed: (%s), args=0xffbfec98) at failures.c:403 #4 0x0007ac5c in i_panic ( format=0x929c8 file %s: line %d (%s): assertion failed: (%s)) at failures.c:183 #5 0x00042cdc in mbox_sync_rewrite (sync_ctx=0xffbff3f8, mail_ctx=0x92800, end_offset=13387, move_diff=40611, extra_space=4295021294, first_seq=1, last_seq=163) at mbox-sync-rewrite.c:579 #6 0x0003e970 in mbox_sync_do (sync_ctx=0xffbff3f8, flags=4290769568) at mbox-sync.c:1332 #7 0x0003f554 in mbox_sync (mbox=0xc1c48, flags=MBOX_SYNC_UNDIRTY) at mbox-sync.c:1800 #8 0x0003f988 in mbox_storage_sync_init (box=0xc1c48, flags=MAILBOX_SYNC_FLAG_FULL_READ) at mbox-sync.c:1869 #9 0x0006c83c in mailbox_sync_init (box=0xc1c48, flags=MAILBOX_SYNC_FLAG_FULL_READ) at mail-storage.c:406 #10 0x000298a8 in imap_sync_nonselected (box=0xc1c48, flags=MAILBOX_SYNC_FLAG_FULL_READ) at imap-sync.c:196 #11 0x00021154 in _cmd_select_full (cmd=0xbbd7c, readonly=false) at cmd-select.c:39 #12 0x000212f0 in cmd_select (cmd=0xbbd7c) at cmd-select.c:92 #13 0x00022d68 in client_handle_input (cmd=0xbbd7c) at client.c:332 #14 0x00022ce0 in client_handle_input (cmd=0xbbd7c) at client.c:389 #15 0x00022ee0 in _client_input (context=0xbbd38) at client.c:432 #16 0x0008100c in io_loop_handler_run (ioloop=0xb9530) at ioloop-poll.c:199 #17 0x000808c8 in io_loop_run (ioloop=0xb9530) at ioloop.c:323 #18 0x0002b400 in main (argc=-4195374, argv=0xaf800, envp=0xb0be4) at main.c:287 I still have the core, in case there is other information from gdb that would be useful in diagnosing this. -- Steven F. Siirila Office: Lind Hall, Room 130B Internet Services E-mail: [EMAIL PROTECTED] Office of Information TechnologyVoice: (612) 626-0244 University of Minnesota Fax: (612) 626-7593
Re: [Dovecot] assertion failed (1.0-rc27)
On Thu, Mar 29, 2007 at 01:38:59AM +0300, Timo Sirainen wrote:
On 29.3.2007, at 1.10, Steven F Siirila wrote:
Anyway if it happened repeatedly, it would be nice to get the
anonymized mbox and index files. See http://wiki.dovecot.org/
MboxProblems
I have reproduced this on a test box; here is the backtrace from
the core
that was generated:
Can you reproduce this multiple times? If so, I'd really like the
mbox file (anonymized) and the index files. It's much easier to fix
the problem if I can reproduce it myself.
I'll see what I can put together; however, let me know if the
information below turns out to be sufficient...
I still have the core, in case there is other information from gdb
that
would be useful in diagnosing this.
At least:
fr 5
#5 0x00042cdc in mbox_sync_rewrite (sync_ctx=0xffbff3f8, mail_ctx=0x92800,
end_offset=13387, move_diff=40611, extra_space=4295021294, first_seq=1,
last_seq=163) at mbox-sync-rewrite.c:579
579 i_assert(move_diff + (off_t)expunged_space = 0);
p *mail_ctx
$1 = {sync_ctx = 0x5f676574, mail = {uid = 2036297574, idx_seq = 1718838644,
keywords = {buffer = 0x0, element_size = 0}, flags = 114 'r',
uid_broken = 0 '\0', expunged = 1 '\001', pseudo = 1 '\001',
from_offset = 4495277855392886630, body_size = 7382355763620035872,
offset = 2915358819387143209, space = 3256384005565579264},
seq = 1769174130, hdr_offset = 824244805484408,
body_offset = 6874574906695249764, header_first_change = 2036298601,
header_last_change = 2053439488, header = 0x72737472,
hdr_md5_sum = eam-hdr_offset , content_length = 8462094814726596909,
hdr_pos = {822083584, 0, 1920169074, 1700883757, 1047355753},
parsed_uid = 1818194793, last_uid_updated_value = 2053447713,
last_uid_value_start_pos = 1025517685, have_eoh = 0, need_rewrite = 1,
seen_imapbase = 1, updated = 0, recent = 1, dirty = 1, imapbase_rewrite = 1,
imapbase_updated = 1}
p *sync_ctx
$2 = {mbox = 0xc1c48, flags = MBOX_SYNC_UNDIRTY, input = 0xc6bd0,
file_input = 0xc6ab0, write_fd = 8, orig_mtime = 1175119566,
orig_size = 36478386, index_sync_ctx = 0xc30b8, sync_view = 0xc30f0,
t = 0xc46a0, hdr = 0xc3138, header = 0xba6a0, from_line = 0xba678,
base_uid_validity = 1155907017, base_uid_last = 9356,
base_uid_last_offset = 0, mails = {buffer = 0xba6c8, element_size = 56},
syncs = {buffer = 0xba6f0, element_size = 20}, sync_rec = {uid1 = 0,
uid2 = 0, type = 0, add_flags = 0 '\0', remove_flags = 0 '\0',
keyword_idx = 0}, mail_keyword_pool = 0xc48f8,
saved_keywords_pool = 0xc4a00, prev_msg_uid = 9356, next_uid = 10170,
idx_next_uid = 1, seq = 813, idx_seq = 814, need_space_seq = 1,
expunged_space = 0, space_diff = -40662, dest_first_mail = 1,
first_mail_crlf_expunged = 0, delay_writes = 0, renumber_uids = 0,
moved_offsets = 0}
p mails[idx]
$3 = {uid = 9357, idx_seq = 1, keywords = {buffer = 0x0, element_size = 0},
flags = 8 '\b', uid_broken = 0 '\0', expunged = 0 '\0', pseudo = 0 '\0',
from_offset = 0, body_size = 11844, offset = 50, space = -11}
--
Steven F. Siirila Office: Lind Hall, Room 130B
Internet Services E-mail: [EMAIL PROTECTED]
Office of Information TechnologyVoice: (612) 626-0244
University of Minnesota Fax: (612) 626-7593
[Dovecot] Odd error message
We are running Dovecot 1.0-rc27 and have run across what seems to be a fatal error (SIGSEGV) in the past few days (4 times total in past 6 days). It appears to have been 5 separate users, 5 separate remote IP addresses. Two of these have this format: Mar 26 15:13:10 myhostname dovecot: imap-login: Authenticate PLAIN failed: Don't send unrequested data: user=rmtuser, method=PLAIN, rip=10.9.9.9, lip=10.1.1.1, TLS The other three have this format: Mar 26 09:41:45 myhostname dovecot: imap-login: Authenticate PLAIN failed: Don't send unrequested data: method=PLAIN, rip=10.9.9.9, lip=10.1.1.1, TLS Here's the first one a bit more expanded, showing the SIGSEGV (signal 11): Mar 26 15:13:10 myhostname dovecot: auth(default): client in: AUTH 1 PLAIN service=IMAPsecured lip=10.1.1.1rip=10.9.9.9 Mar 26 15:13:10 myhostname dovecot: auth(default): client out: CONT 1 Mar 26 15:13:10 myhostname dovecot: auth(default): client in: CONThidden Mar 26 15:13:10 myhostname dovecot: auth(default): pam(rmtuser,10.9.9.9): lookup service=IMAP Mar 26 15:13:10 myhostname dovecot: auth(default): client out: OK 1 user=rmtuser Mar 26 15:13:10 myhostname dovecot: auth(default): master in: REQUEST 675645 1 Mar 26 15:13:10 myhostname dovecot: auth(default): passwd(rmtuser,10.9.9.9): lookup Mar 26 15:13:10 myhostname dovecot: auth(default): master out: USER 675645 rmtuser system_user=rmtuser uid=9 gid= home=/home/r/rmtuser Mar 26 15:13:10 myhostname dovecot: imap-login: Authenticate PLAIN failed: Don't send unrequested data: user=rmtuser, method=PLAIN, rip=10.9.9.9, lip=10.1.1.1, TLS Mar 26 15:13:10 myhostname dovecot: imap-login: Disconnected: user=rmtuser, method=PLAIN, rip=10.9.9.9, lip=10.1.1.1, TLS Mar 26 15:13:10 myhostname dovecot: child (login) killed with signal 11 What can I do to further diagnose this problem? -- Steven F. Siirila Office: Lind Hall, Room 130B Internet Services E-mail: [EMAIL PROTECTED] Office of Information TechnologyVoice: (612) 626-0244 University of Minnesota Fax: (612) 626-7593
Re: [Dovecot] Dovecot LDA issues
On Mon, Mar 26, 2007 at 03:23:12AM +0300, Timo Sirainen wrote: On Fri, 2007-03-23 at 13:08 -0500, Steven F Siirila wrote: We've seen two issues come up with Dovecot LDA, both of which have caused us problems: 1) If the user's home directory does not exist, or is not owned by them, deliver fails and causes the mail message to bounce back to the originator. In our environment this happens when our user is moved to another server (where we move their files, but for up to 24 hours afterwards, continue to re-mail their /var/mail INBOX). This no longer works because the user has no home directory, causing deliver to fail with Permission denied when attempting to create their home directory for the purposes of creating INBOX index files. Happened with mbox, but not with maildir. Changed to return temporary failure: http://dovecot.org/list/dovecot-cvs/2007-March/008357.html 2) If the user is over quota (in their home directory), deliver fails with a temporary error, causing requeues until the user is back under quota (which in our environment could be a long time, days). Since we've never had quotas on the user's INBOX (in /var/mail), this is a problem for us. .. I'd propose for both of these cases that deliver issue WARNING messages to its logs, and simply not create index files for the INBOX. If the INBOX index files already exist, and the user is over quota in /home, neither deliver nor any other Dovecot process should attempt to update them, and instead issue WARNING messages. This allows the e-mail to be delivered instead of requeued, or worse yet, rejected. Index files are supposed to make things perform better, not worse, in ALL cases. :) For the 1) case.. No. At least not anytime soon. The mail root directory is used for other things than index files as well, and I don't want to add lots of special case checks to make it work in a INBOX-only environment. For 2) case, it should work like that since rc27. What version are you using? We are using rc24 on one server, rc27 on another. Are you saying that it should deliver e-mail to my INBOX (in rc27) even if my home is over quota? I will need to double-check, but I thought this was not the case in either rc24 or rc27, and that it was requeuing instead. -- Steven F. Siirila Office: Lind Hall, Room 130B Internet Services E-mail: [EMAIL PROTECTED] Office of Information TechnologyVoice: (612) 626-0244 University of Minnesota Fax: (612) 626-7593
[Dovecot] Dovecot LDA issues
We've seen two issues come up with Dovecot LDA, both of which have caused us problems: 1) If the user's home directory does not exist, or is not owned by them, deliver fails and causes the mail message to bounce back to the originator. In our environment this happens when our user is moved to another server (where we move their files, but for up to 24 hours afterwards, continue to re-mail their /var/mail INBOX). This no longer works because the user has no home directory, causing deliver to fail with Permission denied when attempting to create their home directory for the purposes of creating INBOX index files. 2) If the user is over quota (in their home directory), deliver fails with a temporary error, causing requeues until the user is back under quota (which in our environment could be a long time, days). Since we've never had quotas on the user's INBOX (in /var/mail), this is a problem for us. I'd propose for both of these cases that deliver issue WARNING messages to its logs, and simply not create index files for the INBOX. If the INBOX index files already exist, and the user is over quota in /home, neither deliver nor any other Dovecot process should attempt to update them, and instead issue WARNING messages. This allows the e-mail to be delivered instead of requeued, or worse yet, rejected. Index files are supposed to make things perform better, not worse, in ALL cases. :) -- Steven F. Siirila Office: Lind Hall, Room 130B Internet Services E-mail: [EMAIL PROTECTED] Office of Information TechnologyVoice: (612) 626-0244 University of Minnesota Fax: (612) 626-7593
[Dovecot] Index files in .imap directory
A few RC releases ago we had a problem where a user's restored home directory contained a .imap folder either from a previous RC release or perhaps it was a different server. In any event, restoration of the user caused problems since Dovecot choked on the restored .imap index files. Removing those index files cleared the problem. I'm wondering if this is still an issue, and therefore whether we need to find and remove all .imap folders prior to archiving users, so that they are not restored with potentially old/bad index files. I would like to NOT have to worry about them, but rather have Dovecot be smart about when to simply re-create them if it detects something it does not like about them. -- Steven F. Siirila Office: Lind Hall, Room 130B Internet Services E-mail: [EMAIL PROTECTED] Office of Information TechnologyVoice: (612) 626-0244 University of Minnesota Fax: (612) 626-7593
