Hello,
I have this problem with cyrus-imapd-2.0.16
last pid: 69049; load averages: 0.16, 0.03, 0.01up 1+19:22:04 08:36:18
1675 processes:1 running, 1674 sleeping
CPU states: 0.0% user, 0.0% nice, 0.6% system, 6.0% interrupt, 93.5%
idle Mem: 473M Active, 296M Inact, 199M Wired, 29M Ca
> I believe I've fixed this bug in CVS (did it a few days ago, actually)
> and it'll be in the next release.
If I understand correctly, this fixes the flat-file seen implementation, but
not the underlying problem, which is that updates to seen are deferred until
the connection is closed. Am I fol
Hi,
While the IMAP server does a great job of supporting multiple languages
for searching. The level of support provided by sieve is much much lower.
Here is an outline of the modifications to cyrus and sieve, which I think
are necessary to enable multi-lingual support in cyrus
Quoting Lawrence Greenfield <[EMAIL PROTECTED]>:
> Actually, for some drives the claim is that, if they are correctly
> functioning, then that _won't_ happen. After all, it takes an
> insignificant amount of time to write a single block to a modern
> drive---there is plenty of power in capacitors
Date: Thu, 12 Dec 2002 20:32:50 -0500
From: "John A. Tamplin" <[EMAIL PROTECTED]>
Correct, but if the power gets cut to the drive during the block
write, all bets are off for the content of that block. True, most
of the time you won't get weird failures but then most of the time
> I don't think I've ever heard of a filesystem that mingles more than
> one file in a single block. (If they do, it's certainly news to me,
> and no reasonable model can be made that will deal with it.) The "out
ResierFS does this (though you can turn it off). One of it's claims is that
it happi
Quoting Lawrence Greenfield <[EMAIL PROTECTED]>:
> Obviously disks do not write one byte at a time. Writes happen to
> blocks of data. However, the operating system will issue the block of
> data identically to the old block except for the byte (or word, or
> whatever) that I've changed.
Correct,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Content-Type: text/plain; charset=us-ascii
Does sieve support filing incoming mail into two mailboxes? I have a user
who want to file much of his mail into one backup folder and then process it
with other filters later. However, I'm finding that l
Jure Pecar wrote:
>
> Hi all,
>
> what is the current status of the cyrus 2.2 cvs branch? judging by the cvs
> commits lately, there are just various little cleanups here and there ... is
> there anything big left on the TODO list for 2.2?
I addition to what Rob already mentioned, there needs
On Thu, 2002-12-12 at 18:20, Lawrence Greenfield wrote:
> You shouldn't do this. Use the rename command inside of cyradm or any
> IMAP client.
Thank you for replying. :)
I was trying to simulate things that could happen during (ab)normal
operation (e.g. fs corruption). I am aware of and use cyra
Quoting Lawrence Greenfield <[EMAIL PROTECTED]>:
> [Sidebar: skiplist makes an assumption that a single byte write might
> be in an interdeterminate state after a crash, that write will not
> affect nearby data that is already known to be on stable storage. On
> reflection I suspect the loop-forev
Date: Thu, 12 Dec 2002 20:00:52 -0500
From: "John A. Tamplin" <[EMAIL PROTECTED]>
[...]
Disks don't write one byte at a time, so a system crash during a
write can result in indeterminate state for the entire block (and
it gets worse when you go through the filesystem rather than raw
--On Friday, December 13, 2002 10:48 AM +1100 Rob Mueller
<[EMAIL PROTECTED]> wrote:
| Yes. I think it's better to at least startup with a reduced DB, then fail
| to start at all.
Which means mail to those poor soles that got dropped from the db will
start bouncing horribly, right? If so, thes
From: "Rob Mueller" <[EMAIL PROTECTED]>
Date: Fri, 13 Dec 2002 10:48:20 +1100
>It's scarier when you see this on the mailboxes DB.
>
> You've had this problem on your mailboxes db? Yuck.
Yes, after system crashes. I think it was a SCSI card/driver problem.
Hmm. Well, this i
>It's scarier when you see this on the mailboxes DB.
>
> You've had this problem on your mailboxes db? Yuck.
Yes, after system crashes. I think it was a SCSI card/driver problem.
> Doing this could destroy most of the database and could be even more
> confusing to system administrators. I gu
From: "Rob Mueller" <[EMAIL PROTECTED]>
Date: Thu, 12 Dec 2002 13:01:48 +1100
Looks like you've got corrupted skiplist files. Delete the seen state
databases with the problem and it will automatically rebuild them.
That's what we do.
It's scarier when you see this on the mailboxes
From: Mike Cathey <[EMAIL PROTECTED]>
Date: 11 Dec 2002 13:05:08 -0500
[...]
I ran into a 'problem' during testing that may be related to the one
you've encountered. I started out using the bdb backend. During
testing, I moved (as in /bin/mv) a physical mailbox (in
/var/spool/i
Date: Tue, 10 Dec 2002 17:02:28 -0700 (MST)
From: RJ45 <[EMAIL PROTECTED]>
I got my mailboxes.db mangled because of a file system problem.
I cannot even delete or modify quota of some accounts anymore, it tells me
mailbox format is invalid.
How can I rebuild the whole mailboxes.
Date: Wed, 11 Dec 2002 10:46:45 -0200
From: Alessandro Oliveira <[EMAIL PROTECTED]>
[...]
Dec 9 09:12:35 intra03 imapd[30212]: DBERROR: skiplist recovery: 0958
should be ADD or DELETE
Dec 9 09:12:35 intra03 imapd[30212]: DBERROR: opening
/var/lib/imap/user/n/natacha.se
I've installed cyrus-imapd-2.1.9nb1 (2.1.9 with NetBSD patch revision 1)
onto a NetBSD 1.6 machine, however I'm getting the following message
regularly (about every 20 minutes or so):
|Dec 9 21:57:16 aeolos ctl_cyrusdb[21042]: DBERROR: archive /mod/var/state/cyrus/db:
|cyrusdb error
|Dec 9 21:5
Hi,
I am trying to find a command from Cyrus IMAP, so that I can tell how may mailbox do I
have on the system. I know 'rlist "" "user.%"' will print out all the user mailboxes.
But Is there a way to just the the user count?
Thanks a lot,
Su Li
Reseach In Motion
(519)888-7465 ext 3041
Rob Siemborski wrote:
The only *possible* advantage I see is it gets cyrus's databases backed up
with an SQL database, but since you still have to back up the cyrus
datastore anyway, you haven't won anything.
Well, most real databases offer online backup capability so you can get
a robust bac
On Thu, 12 Dec 2002, Jure Pecar wrote:
> what is the current status of the cyrus 2.2 cvs branch? judging by the cvs
> commits lately, there are just various little cleanups here and there ... is
> there anything big left on the TODO list for 2.2?
The big one is getting the sieve bytecode support
Hi all,
what is the current status of the cyrus 2.2 cvs branch? judging by the cvs
commits lately, there are just various little cleanups here and there ... is
there anything big left on the TODO list for 2.2?
my little wish would be the sql cyrusdb interface, discussed here a week or
two ago, ev
For archival sake, here's what I found out the second time through this process
on my test server.
1) Make sure that your cyrus user and group can read the databases (any ending
in .db and /var/lib/imap/db/*). I had wrong ownership on some files that was
generating some slightly misleading error
I got skiplist to work temporarily on my HP-UX 11.0 development box by
commenting out the code that searches through the entire mailboxes.db file
for the user you are trying to delete (having permissions on someone else's
mailbox, that is). Then, the little testing I did worked great. In our
school
Rob Siemborski wrote:
[skiplist]
No, it doesn't have a specific in-core cache, it relies on the filesystem
cache alone (it mmap()s the db file and uses that directly).
Can you tell offhand if it does any of the mmap() stuff that's a no-no
on HP-UX platform (eg. same process mapping two overlappi
On Thu, 12 Dec 2002, Jeremy Rumpf wrote:
> Out of sheer curiosity. I'm assuming the skiplist backend also uses an in core
> cache as well? If so, is it also tuneable or does it dynamically extend
> itself?
No, it doesn't have a specific in-core cache, it relies on the filesystem
cache alone (it m
> Cyrus doesn't do anything to increase the BDB cache
> size, and the default (256 kB) is way too small for any reasonably large
> site. With some 5 mailboxes and random operations, I found the hit rate
> for default BDB cache to be 70-80%. After growing the cache size to 2M, hit
> rate approa
Richard Gilbert wrote:
Having watched the activity, the thing which seems to consume most of the
resources are the LIST "" * and LIST "" % commands. These return with a
response like "OK Completed (1.480 secs 28 calls)" but can take a very
long real time. Is there anything which can be done to s
On Thu, 12 Dec 2002, Simon Matter wrote:
> AFAIK, it should be possible to convert all db's on the old server to
> flat, which seems to be the most secure way. Then transfer the data to
> the new server and simply start Cyrus using 'service cyrus-imapd start'.
> All db's should then be converted a
Hi Kevin,
AFAIK, it should be possible to convert all db's on the old server to
flat, which seems to be the most secure way. Then transfer the data to
the new server and simply start Cyrus using 'service cyrus-imapd start'.
All db's should then be converted automagically to the required format.
I
Hello,
I have an update scheduled for our mail server over the Christmas break
(assuming I can get all the snags worked out of the upgrade process). Where I
currently am:
Cyrus-IMAPd v2.1.0pre (from CVS just before SASLv2 was required)
Cyrus-SASL v1.5.27 w/ Simon Loader's LDAP patch
Red Hat Linu
Hi,
Al last I managed to update my 2.0.x RPM packages to 2.0.17
http://www.rmorales.com.ar/rpms/cyrus-imapd/
Some other minor modiffications/fixes I had in the backlog were
implemented in this new release (2.0.17-2rm too) as well.
Regards,
On 4 Dec 2002 at 14:48, Rob Siemborski wrote about "C
34 matches
Mail list logo