Re: failover scenario's for replication
Hi, Bron Gondwana wrote: On Mon, Aug 28, 2006 at 02:23:22PM -0400, Wesley Craig wrote: On 26 Aug 2006, at 16:09, Paul Dekkers wrote: Right now, it looks tricky to me to enable replication after failover, or the replicated machine itself if you're not sure that the replica is identical and the sync-processes finished completely: if a message- file is in place on machine A (say 7.) but it was not replicated to machine B while that one becomes the master, the machine B will create a new file 7. and both machines consider this file synchronised after that: also if roles switch back, you have two different (with one isolated) copies of 7. As I understand it, this is what replication uuids are for. Not that I've experimented with this particular case. All that replication UUIDs do is make sure that the copy of '7' on the master overwrites the copy of '7' on the replica. It doesn't make any attempt to retain '7' from the replica. It doesn't replace it either. As soon as I have a different copy of '7' on my replica it never gets rewritten, for as far as I can see with this simple experiment: 'Haver' is master, 'gerst' is replica. [EMAIL PROTECTED] paul]# md5sum 7. 599307e354e203b706a7ba88d6ad668c 7. [EMAIL PROTECTED] paul]# md5sum 11. md5sum: 11.: No such file or directory [EMAIL PROTECTED] paul]# sudo -u cyrus /usr/lib/cyrus-imapd/sync_client -v -u paul USER paul [EMAIL PROTECTED] paul]# md5sum 7. 32187646fe6176e989b9b59c59f7af9e 7. [EMAIL PROTECTED] paul]# md5sum 11. 41d62ed42df1f058a76831061fb0c4ca 11. [EMAIL PROTECTED] paul]# md5sum 7. 599307e354e203b706a7ba88d6ad668c 7. [EMAIL PROTECTED] paul]# md5sum 11. 41d62ed42df1f058a76831061fb0c4ca 11. Still the previous '7', the new '11' gets replicated correctly. I don't know if this is correct behavior or not, to be honest. (From one perspective I think this is a good thing: if there is a different message(-id) on the other host, no matter what number it has, it should remain there, a new message should be added and maybe even the extra message on the replica should get replicated back to the master. On the other hand: this causes inconsistencies and this is no bidirectional synchronization, the master should be right (unless there was a failover ;-)) so just replace the thing (hmm, have to think that over, still sounds a bit scary and I've had inconsistent 'but still running' filesystems before...)) Or is it only preferred to use a replica if there is a really serious crash on the (previous) master? That's certainly how I view the current system. Until replication is more reliable, I'd be quite leery of any sort of automatic failover. Ditto. Our 'init scripts' actually check a database table to see which role a particular instance on a machine has and then starts up in that mode. Changing over the database table entry is a manual step. The master init script also attempts to run the remaining log files with sync client if there are any. Hmm, sounds like a good idea. (Allthough you can't do that indeed with an unreachable replica ;-) For now I can live with that, maybe I'd just put some other check in front to see if the replica is available or not, check_tcp from Nagios or something.) Sadly, sync_client doesn't interact well with real-time requriements and the replica being away. Bah. I'll get back to my -o = only try to connect ONCE patch one day. It sounds nice to me if I could use heartbeat or (u)carp (/ifstated) like systems to start and stop a sync_client or sync_server copy of cyrus (both different cyrus.conf) as soon as the state of the virtual interface changes, but then it is even more likely that some replication process is not finished without an admin even noticing it. I agree, this is a great goal. I'd be interested in seeing a roadmap for how to achieve it, including how failback would occur. There's a lot of opportunity to share operational experience with Cyrus. If only there was a forum to publish such information... Yeah, I've had a play with using heartbeat. The downside is that its colocation works, but ordering operations without having dependencies take the other side down as well doesn't work properly. You can't say always start the master in preference and start the replica first if you can (makes master startup actually work at the moment!). I haven't tried this; but does it hurt defining sync_server, imapd and friends processes in the replicas cyrus.conf and by that have it identical as the master? If we're not using it while in replica mode I'm curious if it will hurt (same for the sync_server on the master). Then the only switch you'd make between being a replica or master is the sync_client, which is something we currently take out of control of the cyrus.conf anyway ;-) (I'm still thinking of nice ways to control (/automatically restart) the sync_client; It doesn't write out
Re: Another sync-client issue
On Sun, 27 Aug 2006, Bron Gondwana wrote: This is just a copy-and-pasteo that I noticed while looking for the other issue in the sync code tonight. I think the fix is pretty self evident since exactly the same comment exists elsewhere with the correct error code after it and the value that's there now duplicates a test just above and is an unreachable path. Agreed. -- David Carter Email: [EMAIL PROTECTED] University Computing Service,Phone: (01223) 334502 New Museums Site, Pembroke Street, Fax: (01223) 334679 Cambridge UK. CB2 3QH. Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: sync_client bails out after 3 MAILBOXES need upgrading to USER in one run
On Sun, 27 Aug 2006, Bron Gondwana wrote: I've attached my trivial solution (against CVS of last week some time), but I'm thinking a better (as in, less wasteful) solution might be to not return an error at all for a failed mailbox, but instead keep walking the entire tree, and then generate a USER event for every mailbox that hasn't been marked yet. My original code (which we are still running: I'm not in any hurry to upgrade to 2.3) sorts mailbox actions by user. If a single mailbox action associated with a user fails the rest are discarded and a USER event is generated. If the USER event fails it locks the given user out of the mboxlist and tries again. This is close to what you describe above. From memory the 3 retries thing was introduced to cope with transient problems on shared mailboxes, caused by mailboxes moving around under the replication engines feet. No promotion is possible in this case. Ken and David - is there a reason why you chose to pass a single MAILBOXES command with multiple mailboxes to the backend rather than single mailbox commands? The little birdy in my head is whispering (it does that at 1am after many hours of debugging) that it has something to do with supporting renames. Rename and copying messages between mailboxes. With single mailbox commands RENAME becomes DELETE + CREATE/UPLOAD (which would work, but would be a pain if a GByte mailbox was involved). COPY would upload new messages rather than reusing the single instance store on the replica. -- David Carter Email: [EMAIL PROTECTED] University Computing Service,Phone: (01223) 334502 New Museums Site, Pembroke Street, Fax: (01223) 334679 Cambridge UK. CB2 3QH. Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: sync_client stalls the rest of cyrus while 'no route to host'
On Sun, 27 Aug 2006, Bron Gondwana wrote: To tell you the truth, I'm seriously considering writing a replacement to sync_client that does a bunch of different things including multiple replicas, maintaining log files, etc. All of this drops out pretty easily from a pattern which produces a single log file per day and calls the sync_client fork children with a byte-range on the log file to run rather than moving the file and then running the copy. I think that you would be better off with multiple log files and multiple sync_client processes, one for each replica. That way each replication stream is independent and can progress at its own best speed. Particularly important if a replica dies (or is shut down for routine maintenance) and needs to catch up from a big backlog of transactions. -- David Carter Email: [EMAIL PROTECTED] University Computing Service,Phone: (01223) 334502 New Museums Site, Pembroke Street, Fax: (01223) 334679 Cambridge UK. CB2 3QH. Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: sieve doesn't work
Phil Pennock schrieb: If you're only supporting PLAIN and LOGIN then without TLS you need a minimum of 0. sasl_minimum_layer: 1 sieve_sasl_minimum_layer: 0 After reloading and even restarting cyrus with the changes to the sieveshell die line and the imapd.conf in place as suggested, I still get the same (slighty longer but unfortunately no more informative) error message from sieveshell: unable to connect to server () at /usr/bin/sieveshell line 174. Do I need to restart saslauthd to re-read the config from /etc/imapd.conf? Couldn't really see why since cyrus uses auxprop and saslauthd is only used for postfix SASL auth - /etc/defaults/saslauthd: START=YES MECHANISMS=rimap -O localhost -m /var/spool/postfix/saslauthd The libsasl2-modules package is of course installed... Is there maybe an alternative to sieveshell? Telneting sieve seems to return such a correct response... All out of ideas but full of hope ;-) Martin Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: hardware recommendations for MURDER?
Hello, I have the same considerations for an upcoming cyrus murder setup. I would like to continue to use RHEL on HP ProLiant hardware as most of our services are running on it and it works perfectly. While I understand that MUPDATE and the frontends will be idling around most of the time (I think I will use DL360 with Opteron DC or so) and I'm just not sure how much memory I should give them, I'm not sure about the backend hardware. I'm a bit afraid of large systems, because if I have a server with 2 TB of storage, but it can't handle enough concurrent connections, then I won't be able to use the storage available and I have to setup an additional backend server with a lot of storage left unused. How can I calculate how much CPU and memory I need for an average user with a maximum of 100 MB per mailbox and some larger mailboxes like 2 or 5 GB? Would you prefer a really fat system with 16 GB of RAM, 1 TB storage and two dual core Opterons or two separate systems with 500 GB storage, 2-4 GB RAM and one dual core Opteron? I would tend to the latter one (two small systems should be more failsafe than one large, aren't they?). So for the hardware I'm tending between a small DL360 with two big SCSI discs or a big DL385 with 6 drive bays. Regards Marten Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
'inline' in sieve/bc_emit.c
Hi everyone,
The file sieve/bc_emit.c contains an inline function declaration in line
48 (version cyrus-imap-2.2.13):
inline int write_int (int fd, int x)
{
int y=htonl(x);
return (write(fd, y, sizeof(int)));
}
I would like to suggest turning this into a 'static inline', for
portability. The current bc_emit.c causes linker problems when building
it with the Sun Studio compiler. As the function is only used in this
single c-file, using static should not make a difference.
Regards, Paul Boven.
Cyrus Home Page: http://asg.web.cmu.edu/cyrus
Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Berkeley DB upgrade - 2nd try
Hi everyone, Paul Boven wrote: If I build cyrus against the old version (4.1.25), it runs great. If I build it against 4.4.20, it doesn't want to start. Even though I've changed tlscache_db and duplicate_db to 'skiplist' in the imapd.conf and removed those db-files from the system, so it shouldn't even be using Berkeley-db anymore, with all databases being skiplist. Starting with a clean /var/imap, I can start the newly compiled Cyrus, so it has to do with whatever is left in /var/imap/db from the old Berkeley version. I've also done a db_upgrade in /var/imap using the 4.4.20 db_upgrade version, but the Cyrus with the 4.4.20 Berkeley libs still won't start. I'd welcome any suggestions on how to proceed and make this into a working mail-server again. (Don't worry, this is only the testbed - the really scary stuff is yet to come). Progress made since: I've tried to build a Cyrus without any Berkeley by specifying '--without-bdb' - for that, I had to comment out a fixed '#include db.h' in lib/auth_pts.h. But that only resulted in this error message when starting up: Fatal error: cyrusdb backend berkeley not supported. Other people seem to have managed to go without Berkeley, but so far I haven't - and as Berkely has better performance for the deliver.db and tls_sessions.db, that is not the preferred workaround anyway. I've started building cyrus-imapd-2.2.13 - the Cyrus homepage still lists 2.2.12 as the 'current' version, but is apparently outdated a bit. In another posting to this list, Andrew Morgan hinted that Cyrus v2.2.12 and older will not work with Berkeley DB 4.3+ without a patch. With 2.2.13, at least I get a meaningful error out of Berkeley when I start Cyrus: DBERROR db4: Skipping log file /var/imap/db/log.01: historic log version 7 DBERROR db4: /var/imap/db/log.02: log file open failed: No such file or directory DBERROR db4: PANIC: No such file or directory Running db_recover from Berkeley4.4.20 gave me essentially the same errors. In the end, I figured it apparently doesn't care about log.0001, so I moved it aside. This time, it also stopped looking for log.0002 and recovered succesfully. And now Cyrus works again! Before I even want to consider doing this kind of surgery on any of my production Cyrus servers, I'd like to know what would have been in log.0001 - what risks do I run when removing it? Regards, Paul Boven. Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
imaps[6644]: PROTERR: end of file reached
Hello- I have recently set up a cyrus murder with three backends running Cyrus Imapd 2.2.12 using Cyrus SASL 2.1.22 running on Debian Linux. Everything seems to be working fine but I am getting quite a few of these error messages in our imapd.log file on the master/frontend server. imaps[6644]: PROTERR: end of file reached Does anyone know if this is cause for concern. I can see in the source where this message is generated, but there is little documentation as to what is exactly means. Any help would be appreciated. Sincerely, Davin Flatten -- Davin Flatten Unix Systems Administrator University of Massachusetts Amherst, MA 01003 Phone: 413-545-1580 Email: [EMAIL PROTECTED] Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
RE: sync_client stalls the rest of cyrus while 'no route to host'
From David Carter on Tuesday, August 29, 2006 4:52 AM: On Sun, 27 Aug 2006, Bron Gondwana wrote: To tell you the truth, I'm seriously considering writing a replacement to sync_client that does a bunch of different things including multiple replicas, maintaining log files, etc. All of this drops out pretty easily from a pattern which produces a single log file per day and calls the sync_client fork children with a byte-range on the log file to run rather than moving the file and then running the copy. I think that you would be better off with multiple log files and multiple sync_client processes, one for each replica. That way each replication stream is independent and can progress at its own best speed. Particularly important if a replica dies (or is shut down for routine maintenance) and needs to catch up from a big backlog of transactions. I have written some code that implements something much like you describe as a separate daemon outside of Cyrus itself that is an intermediary between the Cyrus sync log file and sync_client. It creates multiple copies of the sync log for each replica and fires off per-replica instances of sync_client at intervals to process replications to multiple replica servers. I've been running it for a while in a setup with two replicas on a small number of test user mailboxes and it seems to do the right thing, but I am probably not really ready yet to rely on it (or perhaps replication as implemented in 2.3.x at all) for larger populations of users. However, since recent conversations here have been on a similar topic, I would like to offer it for comments and discussion and in the event that it may be useful to someone. It is available at http://madole.net/pushmail/ David Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
something strange with sieve
has someone ever sieve working two or three times, and then not, like if the rule was deactivated ? i set the rules with ingo (from the horde framework), and when i mail to the box, the filter works. but then after two or three tests, it doesn't work anymore. when i check the rules, i see that ingo can't read it properly does anyone know about it ? Pascal Valois Pole Universitaire Leonard de Vinci. Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: sync_client bails out after 3 MAILBOXES need upgrading to USER in one run
On 29 Aug 2006, at 04:35, David Carter wrote: My original code (which we are still running: I'm not in any hurry to upgrade to 2.3) sorts mailbox actions by user. If a single mailbox action associated with a user fails the rest are discarded and a USER event is generated. If the USER event fails it locks the given user out of the mboxlist and tries again. This is close to what you describe above. Why is 2.3 different? I'm fairly sure that these issues: 4) xfer onto a replicating backend causes sync_client to exit 8) renaming users causes sync_client to exit would be solved with the algorithm you're using (or the one Bron outlined). :wes Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: sync_client stalls the rest of cyrus while 'no route to host'
On 28 Aug 2006, at 20:33, Bron Gondwana wrote: What else do you have that will kill it? 4) xfer onto a replicating backend causes sync_client to exit 8) renaming users causes sync_client to exit In both of these, size and other load matters. We agree on the design-flaws front, and I'm seriously consider (as I said in another post) rewriting to be a bit more like mysql in the multiple replicas possible design and keeping the sync logs around for double-checking purposes. The pushmail code look interesting. I think this: 5) xfer off a replicating backend doesn't remove data from the replica is a bug, not a design flaw so much. I think the xfer code is just missing a sync_log call. Probably a trivial fix, but I'm working on #s 48 above. No transferring expunged messages matters only from a backup recovery point of view, and we already keep yet another backup[tm] I'd like to eliminate the cost of our YAB[tm], but can't due to the way that expunged messages are treated: 3) xfer doesn't transfer expunged messages 6) removing folders doesn't benefit from delayed expunge 9) the IMAP rename command doesn't keep expunged messages Oh, and if real-time replication is running the expunged message seems to get itself to the replica before actually getting deleted most of the time. And that would be almost good enough if the other flaws in delayed expunge weren't there. :wes Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
deliver.db conversion to skiplist
I have read many threads regarding issues with deliver.db being in Berkeley
DB format. I am running cyrus-imapd-2.2.3-4 on Redhat AS3. I have not
had any issues with deliver.db until last week. I have about 200 accounts
with
most at 250MB, some at 500MB and a few at 1GB.
The issue started with messages as ...
relay=/var/lib/imap/socket/lmtp[/var/lib/imap/socket/lmtp], delay=40033,
status=deferred (conversation with
/var/lib/imap/socket/lmtp[/var/lib/imap/socket/lmtp] timed out while
sending end of data -- message may be sent more than once)
Aug 24 10:50:33 chipmunk lmtpunix[18926]: DBERROR db4: 1382 lockers
Aug 24 10:50:33 chipmunk lmtpunix[18963]: executed
Aug 24 10:50:33 chipmunk lmtpunix[18963]: DBERROR: opening
/var/lib/imap/deliver.db: Cannot allocate memory
Aug 24 10:50:33 chipmunk lmtpunix[18963]: DBERROR: opening
/var/lib/imap/deliver.db: cyrusdb error
Aug 24 10:50:33 chipmunk lmtpunix[18963]: FATAL: lmtpd: unable to init
duplicate delivery database
A reboot did not fix the problem, but after I reconstructed the mailboxes
from a flatfile - it took 6 hours and then restarted everything, the issue
with lmtp refusing connections still existed. Oddly, the issue corrected
itself about a hour later?
I've read that stopping the server and simply removing the deliver.db and
tls_connections.db (in Berkeley format) and then restarting will result in
no harm. I also read that concverting a large Berkeley deliver.db(mine is
26MB) could take a long time ad result in a skiplist file of huge
proportions.
My question is - should I convert the deliver.db to skiplist? If I simply
move it elsewhere and change the imapd.conf to use a deliver.db in skiplist
and restart, what is lost? Surely this huge db contains information
necessary and useful to the message system?
Any illumination on this is appreciated.
S.Waltz
{ Shelley Waltz;
Center for Advanced Biotechnology and Medicine;
Rutgers University/UMDNJ;
679 Hoes Lane;
Piscataway, NJ 08854;
732 235 3346 }
Cyrus Home Page: http://asg.web.cmu.edu/cyrus
Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: failover scenario's for replication
On 29 Aug 2006, at 04:11, Paul Dekkers wrote: I haven't tried this; but does it hurt defining sync_server, imapd and friends processes in the replicas cyrus.conf and by that have it identical as the master? If you tell the replica where mupdate is, sync_server behaves incorrectly. I'd also avoid running imapd on a replica, unless I could guarantee that users couldn't get to it. (I'm still thinking of nice ways to control (/automatically restart) the sync_client; It doesn't write out a pid, daemon (on FreeBSD) doesn't create the right pidfile for the thing, so things like monit or the restartwrapper fail to control the thing... It doesn't stay in foreground while in rolling mode... Maybe just have check_procs from Nagios look at the process-string (or any other thing that looks in /proc or ps). What do others do? Wesley's suggestion for having a seperate init-script in the same runlevel still looks 'manual' to me, and/or that's not the part that generates an alert. We run the attached script periodically. Maybe I'd write a patch for staying in foreground and/or writing out a pidfile ;-)) We've toyed with the idea of making it stay in the foreground, so we could run it from init. In the current implementation, tho, when it exits it needs operator intervention, so automatic restart is no use -- it will just exit again. The real solution is to make the code more resilient. And on a separate track, we need an overarching strategy for high availability. :wes replnag Description: Binary data Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
RE: sync_client bails out after 3 MAILBOXES need upgrading to USER in one run
The main reason things changed is sypport for shared mailboxes. I can't elaborate now because I'm driving. -- Kenneth Murchison Systems Programmer Project Cyrus Developer/Maintainer Carnegie Mellon University -Original Message- From: Wesley Craig [EMAIL PROTECTED] To: David Carter [EMAIL PROTECTED] Cc: Bron Gondwana [EMAIL PROTECTED]; Ken Murchison [EMAIL PROTECTED]; Info Cyrus info-cyrus@lists.andrew.cmu.edu Sent: 8/29/06 11:05 AM Subject: Re: sync_client bails out after 3 MAILBOXES need upgrading to USER in one run On 29 Aug 2006, at 04:35, David Carter wrote: My original code (which we are still running: I'm not in any hurry to upgrade to 2.3) sorts mailbox actions by user. If a single mailbox action associated with a user fails the rest are discarded and a USER event is generated. If the USER event fails it locks the given user out of the mboxlist and tries again. This is close to what you describe above. Why is 2.3 different? I'm fairly sure that these issues: 4) xfer onto a replicating backend causes sync_client to exit 8) renaming users causes sync_client to exit would be solved with the algorithm you're using (or the one Bron outlined). :wes Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: deliver.db conversion to skiplist
Use db_recover
Shelley Waltz wrote:
I have read many threads regarding issues with deliver.db being in Berkeley
DB format. I am running cyrus-imapd-2.2.3-4 on Redhat AS3. I have not
had any issues with deliver.db until last week. I have about 200 accounts
with
most at 250MB, some at 500MB and a few at 1GB.
The issue started with messages as ...
relay=/var/lib/imap/socket/lmtp[/var/lib/imap/socket/lmtp], delay=40033,
status=deferred (conversation with
/var/lib/imap/socket/lmtp[/var/lib/imap/socket/lmtp] timed out while
sending end of data -- message may be sent more than once)
Aug 24 10:50:33 chipmunk lmtpunix[18926]: DBERROR db4: 1382 lockers
Aug 24 10:50:33 chipmunk lmtpunix[18963]: executed
Aug 24 10:50:33 chipmunk lmtpunix[18963]: DBERROR: opening
/var/lib/imap/deliver.db: Cannot allocate memory
Aug 24 10:50:33 chipmunk lmtpunix[18963]: DBERROR: opening
/var/lib/imap/deliver.db: cyrusdb error
Aug 24 10:50:33 chipmunk lmtpunix[18963]: FATAL: lmtpd: unable to init
duplicate delivery database
A reboot did not fix the problem, but after I reconstructed the mailboxes
from a flatfile - it took 6 hours and then restarted everything, the issue
with lmtp refusing connections still existed. Oddly, the issue corrected
itself about a hour later?
I've read that stopping the server and simply removing the deliver.db and
tls_connections.db (in Berkeley format) and then restarting will result in
no harm. I also read that concverting a large Berkeley deliver.db(mine is
26MB) could take a long time ad result in a skiplist file of huge
proportions.
My question is - should I convert the deliver.db to skiplist? If I simply
move it elsewhere and change the imapd.conf to use a deliver.db in skiplist
and restart, what is lost? Surely this huge db contains information
necessary and useful to the message system?
Any illumination on this is appreciated.
S.Waltz
{ Shelley Waltz;
Center for Advanced Biotechnology and Medicine;
Rutgers University/UMDNJ;
679 Hoes Lane;
Piscataway, NJ 08854;
732 235 3346 }
Cyrus Home Page: http://asg.web.cmu.edu/cyrus
Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Cyrus Home Page: http://asg.web.cmu.edu/cyrus
Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: deliver.db conversion to skiplist
my distro (cyrus-imapd-2.2.3-4) does not appear to have db_recover?
Rafael Alcalde said:
Use db_recover
Shelley Waltz wrote:
I have read many threads regarding issues with deliver.db being in
Berkeley
DB format. I am running cyrus-imapd-2.2.3-4 on Redhat AS3. I have not
had any issues with deliver.db until last week. I have about 200
accounts
with
most at 250MB, some at 500MB and a few at 1GB.
The issue started with messages as ...
relay=/var/lib/imap/socket/lmtp[/var/lib/imap/socket/lmtp], delay=40033,
status=deferred (conversation with
/var/lib/imap/socket/lmtp[/var/lib/imap/socket/lmtp] timed out while
sending end of data -- message may be sent more than once)
Aug 24 10:50:33 chipmunk lmtpunix[18926]: DBERROR db4: 1382 lockers
Aug 24 10:50:33 chipmunk lmtpunix[18963]: executed
Aug 24 10:50:33 chipmunk lmtpunix[18963]: DBERROR: opening
/var/lib/imap/deliver.db: Cannot allocate memory
Aug 24 10:50:33 chipmunk lmtpunix[18963]: DBERROR: opening
/var/lib/imap/deliver.db: cyrusdb error
Aug 24 10:50:33 chipmunk lmtpunix[18963]: FATAL: lmtpd: unable to init
duplicate delivery database
A reboot did not fix the problem, but after I reconstructed the
mailboxes
from a flatfile - it took 6 hours and then restarted everything, the
issue
with lmtp refusing connections still existed. Oddly, the issue
corrected
itself about a hour later?
I've read that stopping the server and simply removing the deliver.db
and
tls_connections.db (in Berkeley format) and then restarting will result
in
no harm. I also read that concverting a large Berkeley deliver.db(mine
is
26MB) could take a long time ad result in a skiplist file of huge
proportions.
My question is - should I convert the deliver.db to skiplist? If I
simply
move it elsewhere and change the imapd.conf to use a deliver.db in
skiplist
and restart, what is lost? Surely this huge db contains information
necessary and useful to the message system?
Any illumination on this is appreciated.
S.Waltz
{ Shelley Waltz;
Center for Advanced Biotechnology and Medicine;
Rutgers University/UMDNJ;
679 Hoes Lane;
Piscataway, NJ 08854;
732 235 3346 }
Cyrus Home Page: http://asg.web.cmu.edu/cyrus
Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
{ Shelley Waltz;
Center for Advanced Biotechnology and Medicine;
Rutgers University/UMDNJ;
679 Hoes Lane;
Piscataway, NJ 08854;
732 235 3346 }
Cyrus Home Page: http://asg.web.cmu.edu/cyrus
Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: deliver.db conversion to skiplist
On 29 Aug 2006, at 11:22, Shelley Waltz wrote:
My question is - should I convert the deliver.db to skiplist? If I
simply
move it elsewhere and change the imapd.conf to use a deliver.db in
skiplist
and restart, what is lost? Surely this huge db contains information
necessary and useful to the message system?
The database contains message-IDs of already delivered messages. It
is used to suppress duplicate messages to the same users. Removing
the database may allow some (small) number of duplicates to be
delivered. You should have a line like:
EVENTS {
# expire messages and deliver.db entries
delprunecmd=cyr_expire -E 1 at=0300
}
in your cyrus.conf file. This ought to keep deliver.db from growing
out of bounds. If deliver.db has become corrupt, simply deleting it
is a good plan.
:wes
Cyrus Home Page: http://asg.web.cmu.edu/cyrus
Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Mailbox does not exist
Hi all, I am new to this list but didn't to search the archives, so I hope this question is not disturbing anyone. I have a brand new fetchmail procmail cyrus-imapd setup on a FreeBSD 6.0-RELEASE (amd64) machine. all is working very well, except for delivery of mails into specific user mailboxes. alex # su - cyrus %cyradm localhost Password: localhost lm user.bbbart (\HasChildren) user.bbbart.Drafts (\HasNoChildren) user.bbbart.Kapaza (\HasNoChildren) user.bbbart.Lists (\HasChildren) user.bbbart.Lists.cyrus (\HasChildren) user.bbbart.Lists.cyrus.info (\HasNoChildren) user.bbbart.Lists.gphoto (\HasChildren) user.bbbart.Lists.gphoto.devel (\HasNoChildren) user.bbbart.Lists.gphoto.user (\HasNoChildren) user.bbbart.Lists.mod_survey (\HasChildren) user.bbbart.Lists.mod_survey.devel (\HasNoChildren) user.bbbart.Lists.mod_survey.discussion (\HasNoChildren) user.bbbart.OldMail (\HasChildren) user.bbbart.OldMail.2002 (\HasNoChildren) user.bbbart.OldMail.2003 (\HasNoChildren) user.bbbart.OldMail.2004 (\HasNoChildren) user.bbbart.OldMail.2005 (\HasNoChildren) user.bbbart.Sent (\HasNoChildren) user.bbbart.Trash (\HasNoChildren) user.bbbart.eBay (\HasNoChildren) localhost %logout alex # echo | /usr/local/cyrus/bin/deliver -m user.bbbart.Lists.gphoto.devel +user.bbbart.Lists.gphoto.devel: Mailbox does not exist alex # logout [EMAIL PROTECTED] ~ $ echo | /usr/local/cyrus/bin/deliver -m Lists.gphoto.devel +Lists.gphoto.devel: Mailbox does not exist course, when I specify the user bbbart at the end of the deliver statement, the empty mail gets delivered in my INBOX, but this is not what I want. can anyone explain this? thanks a lot! -- kind regards, Bart Van Loon One of the joys of being a kid is that experiences are new and therefore more intense. -Calvin sniffing mustard Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Mailbox does not exist
Hi Bart, user.bbbart.Lists.gphoto.devel (\HasNoChildren) [...] alex # echo | /usr/local/cyrus/bin/deliver -m user.bbbart.Lists.gphoto.devel +user.bbbart.Lists.gphoto.devel: Mailbox does not exist alex # logout [EMAIL PROTECTED] ~ $ echo | /usr/local/cyrus/bin/deliver -m Lists.gphoto.devel +Lists.gphoto.devel: Mailbox does not exist course, when I specify the user bbbart at the end of the deliver statement, the empty mail gets delivered in my INBOX, but this is not what I want. I don't know wheter I understood what you want - the question I got was: how can I make cyrus deliver use the mailbox subhierarchy of the currently logged in user? In that case: what you've seen is the expected behaviour. There is no mailbox named Lists.ghoto.devel; cyrus deliver does not care about what name the calling user has. The system is ignorant of the system users by design - it's a black box. So if you want to work around that, you could either specify the user, create an alias in the shell or something similar. However, you may run into permission trouble - as the mailboxes are in some folder tree that belongs to the cyrus user, you cannot distinguish the users there - either you allow anybody (including the nobody account) to deliver mails anywhere or you just deny it to anybody except the cyrus user or group. Baltasar Baltasar Cevc _ former 03 gmbh _ infanteriestraße 19 haus 6 eg _ D-80797 muenchen _ http://www.former03.de Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Mailbox does not exist
* Bart Van Loon wrote [Tuesday, August 29, 2006 07:57:30 PM +0200] Hi all, I am new to this list but didn't to search the archives, so I hope this question is not disturbing anyone. [...] alex # echo | /usr/local/cyrus/bin/deliver -m user.bbbart.Lists.gphoto.devel +user.bbbart.Lists.gphoto.devel: Mailbox does not exist alex # logout [EMAIL PROTECTED] ~ $ echo | /usr/local/cyrus/bin/deliver -m Lists.gphoto.devel +Lists.gphoto.devel: Mailbox does not exist course, when I specify the user bbbart at the end of the deliver statement, the empty mail gets delivered in my INBOX, but this is not what I want. can anyone explain this? My understanding is that you should feed deliver the email address and not the internal cyrus mailbox name, in your case bbat+Lists.gphoto.devel [EMAIL PROTECTED] --- mitu Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Berkeley DB upgrade - 2nd try
On Tue, 29 Aug 2006, Paul Boven wrote: Progress made since: I've tried to build a Cyrus without any Berkeley by specifying '--without-bdb' - for that, I had to comment out a fixed '#include db.h' in lib/auth_pts.h. But that only resulted in this error message when starting up: Fatal error: cyrusdb backend berkeley not supported. Other people seem to have managed to go without Berkeley, but so far I haven't - and as Berkely has better performance for the deliver.db and tls_sessions.db, that is not the preferred workaround anyway. I've started building cyrus-imapd-2.2.13 - the Cyrus homepage still lists 2.2.12 as the 'current' version, but is apparently outdated a bit. In another posting to this list, Andrew Morgan hinted that Cyrus v2.2.12 and older will not work with Berkeley DB 4.3+ without a patch. With 2.2.13, at least I get a meaningful error out of Berkeley when I start Cyrus: DBERROR db4: Skipping log file /var/imap/db/log.01: historic log version 7 DBERROR db4: /var/imap/db/log.02: log file open failed: No such file or directory DBERROR db4: PANIC: No such file or directory Running db_recover from Berkeley4.4.20 gave me essentially the same errors. In the end, I figured it apparently doesn't care about log.0001, so I moved it aside. This time, it also stopped looking for log.0002 and recovered succesfully. And now Cyrus works again! Before I even want to consider doing this kind of surgery on any of my production Cyrus servers, I'd like to know what would have been in log.0001 - what risks do I run when removing it? If you have already eliminated all uses of Berkeley DB in your Cyrus backends (check your imapd.conf file), then anything in those log.xxx files is junk anyways. :) On my production Cyrus servers, I do not use Berkeley DB at all. And yet I still have __db.00x and log.xxx files in the db directory. The timestamps on those files correspond to the last time I restarted Cyrus. Go figure. However, I do see that imapd processes have some of those files open (lsof output), so maybe there is still some use for them that I'm not aware of. Andy Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: sync_client stalls the rest of cyrus while 'no route to host'
On Tue, 29 Aug 2006 09:51:49 +0100 (BST), David Carter [EMAIL PROTECTED] said: On Sun, 27 Aug 2006, Bron Gondwana wrote: To tell you the truth, I'm seriously considering writing a replacement to sync_client that does a bunch of different things including multiple replicas, maintaining log files, etc. All of this drops out pretty easily from a pattern which produces a single log file per day and calls the sync_client fork children with a byte-range on the log file to run rather than moving the file and then running the copy. I think that you would be better off with multiple log files and multiple sync_client processes, one for each replica. That way each replication stream is independent and can progress at its own best speed. Particularly important if a replica dies (or is shut down for routine maintenance) and needs to catch up from a big backlog of transactions. I fail to see the difference between this and a single big log file where each replica keeps track of where it's up to in the log file and then seeks to that spot, reads up to say 10,000 lines and processes that, then stores the new location so they next process can seek directly there before starting. This pattern means a lot less copying data to multiple log files and deleting again. It certainly doesn't mean every replica needs to be at the same point in the log file! This is how mysql handles replication - with each replica keep track of two values - which log file it's in (they're numbered sequentially starting from 1, and going up to wherever you get to before you reset replication for some reason) and how many bytes through that file it is. Bron. -- Bron Gondwana [EMAIL PROTECTED] Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: sync_client stalls the rest of cyrus while 'no route to host'
On 29 Aug 2006, at 18:38, Bron Gondwana wrote: I fail to see the difference between this and a single big log file where each replica keeps track of where it's up to in the log file and then seeks to that spot, reads up to say 10,000 lines and processes that, then stores the new location so they next process can seek directly there before starting. I like multiple log files for two reasons. First, it allows me as an admin to use a tool like ls to decide how far along any particular replica is. Second, code exists that does this. This pattern means a lot less copying data to multiple log files and deleting again. Log files are pretty small. :wes Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
