On Sat, 25 Feb 2006 09:59:31 +1100
"Rob Mueller" <[EMAIL PROTECTED]> wrote:
> We have seen many strange problems with BDB over the years. It's taken quite
> a bit of fiddling of /var/imap/db/DB_CONFIG values to get a BDB environment
> that will run stably over extended periods and loads and on l
Am Fr, den 24.02.2006 schrieb Сергей Осипов um 21:18:
> In imapd.conf I have option "unixhierarchysep: yes".
> If I create mailbox with char '.', for example 'test.test', Cyrus pop3d write
> to log:
> Feb 24 22:35:07 pop3[22096]: login: ..ru [XXX.XXX.XXX.XXX] test.test
> plaintext User l
be careful. in general, deleting transactions which haven't been
applied to the database isn't a good solution. but since you're only
using Berkeley for duplicate_db, which is non-critical, it is fine in
your setting.
I don't know anyone who uses BDB for critical DB's in cyrus. They're too b
Again I'm new to cyrus
In case it is relevant this is what I have to far.
Running debian sarge.
Running lvm on software raid1.
Have about 10gb mail.
It's not on line yet.
Thinking of each night doing:
stop cyrus
making snapshot of the cyrus partition
start cyrus
do backups of snapshot
bl
Hi,
i have a simple Question, I hope.
Is there a nice way do delete duplicate messages from a Cyrus Mailbox.
Messages which are inserted into the mailbox via LMTP get deleted if there
is a duplicate. But there are several messages which weren't inserted this
way.
And those are blowing up the mailb
In imapd.conf I have option "unixhierarchysep: yes".
If I create mailbox with char '.', for example 'test.test', Cyrus pop3d write
to log:
Feb 24 22:35:07 pop3[22096]: login: ..ru [XXX.XXX.XXX.XXX] test.test
plaintext User logged in
Feb 24 22:35:12 pop3[22096]: Unable to locate maildrop f
I've found a '#yrus.cache' instead of cyrus.cach in a mailbox directory, the
user was unable to access it (I/O error).
What could it be ? It's a 2.3.1 system..
Fabio Rossetti
Cyrus Home Page: http://asg.web.cmu.edu/cyrus
Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu
List Archives/Info:
On Fri, 24 Feb 2006, Igor Brezac wrote:
> >It is *much* more stable than 4.x. if you're using DB3 from a distro (e.g.
> >Debian's). But it is slower, though.
>
> The stability of DB3 over DB4 is arguable. OpenLDAP folks will disagree
> with you. Also my experience is with Solaris in this regar
On Fri, 24 Feb 2006, Henrique de Moraes Holschuh wrote:
On Fri, 24 Feb 2006, Igor Brezac wrote:
This is really not neccassry unless the berkeley database is corrupt.
Use 'db_recover' to reset the berkeley environment while cyrus server is
not running.
Cyrus itself attempts to db_recover at s
On Fri, 24 Feb 2006, Igor Brezac wrote:
> This is really not neccassry unless the berkeley database is corrupt.
> Use 'db_recover' to reset the berkeley environment while cyrus server is
> not running.
Cyrus itself attempts to db_recover at startup. Or at least it used to...
It is the reason wh
On 2006-02-24 11:39:08 -0500 Henrique de Moraes Holschuh
<[EMAIL PROTECTED]> wrote:
On Fri, 24 Feb 2006, Igor Brezac wrote:
This is really not neccassry unless the berkeley database is
corrupt. Use
'db_recover' to reset the berkeley environment while cyrus server is
not
running.
Cyrus its
On Fri, 24 Feb 2006, Kjetil Torgrim Homme wrote:
On Fri, 2006-02-24 at 21:39 +1100, Rob Mueller wrote:
When I shut down Cyrus cleanly, which of the files in /var/lib/cyrus/db
can be deleted safely along with deliver.db then?
FYI, we're using 2.3 and have:
duplicate_db: berkeley-nosync
seens
2006/2/24, Craig White <[EMAIL PROTECTED]>:
> On Fri, 2006-02-24 at 09:35 +0100, Andrzej Kwiatkowski wrote:
> > Hello
> >
> > I've noticed such problem with imapd 2.3.1
> >
> > users mailbox dir:
> >
> > -rw-r--r-- 1 cyrus cyrus 7691 2006-02-24 09:25 1.
> > -rw-r--r-- 1 cyrus cyrus 2209 2006-
On Fri, 2006-02-24 at 21:39 +1100, Rob Mueller wrote:
> > When I shut down Cyrus cleanly, which of the files in /var/lib/cyrus/db
> > can be deleted safely along with deliver.db then?
>
> FYI, we're using 2.3 and have:
>
> duplicate_db: berkeley-nosync
> seenstate_db: skiplist
> subscription_db:
On Fri, 2006-02-24 at 09:35 +0100, Andrzej Kwiatkowski wrote:
> Hello
>
> I've noticed such problem with imapd 2.3.1
>
> users mailbox dir:
>
> -rw-r--r-- 1 cyrus cyrus 7691 2006-02-24 09:25 1.
> -rw-r--r-- 1 cyrus cyrus 2209 2006-02-24 09:25 2.
> -rw--- 1 cyrus cyrus 236180 2006-02-2
On Fri, Feb 24, 2006 at 01:42:14PM +0100, Hans Moser wrote:
> Hi!
>
> We're starting a new test with cyrus imapd, which will end up in a
> production setup in the next few month.
>
> Shall we test with the stable 2.2.12 or 2.3.1?
> In general I would prefer "stable", but if 2.3.x will become sta
Hi!
We're starting a new test with cyrus imapd, which will end up in a
production setup in the next few month.
Shall we test with the stable 2.2.12 or 2.3.1?
In general I would prefer "stable", but if 2.3.x will become stable in
the next time (before we'll get in production), it will be bette
When I shut down Cyrus cleanly, which of the files in /var/lib/cyrus/db
can be deleted safely along with deliver.db then?
FYI, we're using 2.3 and have:
duplicate_db: berkeley-nosync
seenstate_db: skiplist
subscription_db: flat
mboxlist_db: skiplist
And our cyrus start script does:
#
Simon Matter wrote:
I guess your cyrus configdirectory is /var/lib/cyrus. Then, did you try
removing the transaction logs in /var/lib/cyrus/db after removing
deliver.db and tls_cache.db?
No, I didn't. I've thought about it, but none of the messages I've read
in the archives mentioned deleting
Hi there,
when I looking up all runnning processes with "ps aux" I
see a lot of old ctl_cyrusdb -c processes.
Example:
I started my server on the 30.01 and from then till now I got
entries like this:
cyrus 27075 0.0 0.0 22276 168 ? S Jan30 0:00 ctl_cyrusdb -c
The process is running ever
HelloI've noticed such problem with imapd 2.3.1users mailbox dir:-rw-r--r-- 1 cyrus cyrus 7691 2006-02-24 09:25 1.-rw-r--r-- 1 cyrus cyrus 2209 2006-02-24 09:25 2.-rw--- 1 cyrus cyrus 236180 2006-02-24 09:25 3.
-rw--- 1 cyrus cyrus 116289 2006-02-24 09:25 4.-rw--- 1 cyrus cyrus
21 matches
Mail list logo
