Re: Fixing stale entries in 'mailboxes.db'...

--On 18 March 2019 at 12:34:12 +0100 Sebastian Hagedorn wrote: user.kpielorz.Archive.1-OldLogs16 (null) [snip] Anyone seem similar, or know what can be done with them? I believe those are "tombstone entries" to mark folders that previously existed and are are safe to keep

Fixing stale entries in 'mailboxes.db'...

Hi, We're running Cyrus IMAP 2.5.12 under FreeBSD. While 'spring cleaning' one of our IMAP servers - aside from having to reconstruct a mailbox, I also found in 'mailboxes.db' (seen via 'ctl_mboxlist -d') we have some entries that have no corresponding directories on the disk, e.g.

Re: Cyrus 2.5.12 - 'reconstruct' - doesn't? - resolved.

Ok, I've finally twigged / resolved this... It looks like the actual directory in question was indeed orphaned from mailboxes.db - due to an issue with names and spaces. If you miss-spell the name of the mailbox - 'reconstruct' / 'mbexamine' et'al just return without doing anything. This

Re: Cyrus 2.5.12 - 'reconstruct' - doesn't?

--On 13 March 2019 at 13:03:03 -0400 Dave McMurtrie wrote: Are the files on disk owned by user 'cyrus' or are they owned by root? All owned by cyrus:cyrus - if I pick "any other mailbox" (which looks identical disk wise) - reconstruct runs, and outputs the name of the mailbox it just

Cyrus 2.5.12 - 'reconstruct' - doesn't?

Hi, I have a Cyrus 2.5.12 server running under FreeBSD. The other day I found thousands of files in an old mailbox. The client can't see any of them - so I thought "Ok, I'll reconstruct the mailbox" Reconstruct runs, and returns instantly - but the client still can't see the files. As

Re: db5 / PANIC errors under 2.5.12?

This just happened again, on a different server... Having spent more time looking at this - the error: Nov 21 07:45:30 imaps[72501]: DBERROR db5: BDB1581 File handles still open at environment close I'm guessing "db5" is indeed Berkeley DB5 - so even though in our imapd.conf we don't

Re: db5 / PANIC errors under 2.5.12?

--On 16 November 2018 13:52 +1100 ellie timoney wrote: Since you've recently upgraded from 2.3 to 2.5, it might be a good opportunity to migrate your Cyrus databases to one of the other database backends such as twoskip or skiplist? It looks like the problems you are having are

Re: db5 / PANIC errors under 2.5.12?

--On 12 November 2018 at 08:40:39 + Karl Pielorz wrote: It'll be a few weeks now (typically) before this happens again. This just happened again - but doesn't appear to be related to connections we just had logged: " Nov 15 18:31:00 imap[84552]: DBERROR db5: pthread su

db5 / PANIC errors under 2.5.12?

Hi, I've recently upgraded a system from Cyrus IMAP 2.5.3 I think it was to 2.5.12 - and started seeing problems with the __db.00* files. In the logs we see: Nov 11 22:43:15 imaps[26220]: imaps TLS negotiation failed: some.isp.domain.com [a.b.c.d] Nov 11 22:43:15 imaps[26221]: imaps TLS

Re: Query re. 'private' vs. 'shared' annotations...

--On 17 February 2017 12:07 +1100 ellie timoney wrote: But, for the purposes of expiry, cyr_expire runs as an admin user, so I think it's not going to see various users own private annotations, which means in order for expiry to work the shared expire annotation seems like

Query re. 'private' vs. 'shared' annotations...

Hi All, We've recently moved from Cyrus 2.4.x to Cyrus 2.5.x - we have a number of expiry annotations setup on some mailboxes. If I use 'cyradm' and 'info' - I can see: private: check: NIL checkperiod: NIL comment: NIL sort: NIL specialuse: NIL thread: NIL expire: NIL

Re: Safe to delete apparently stale / aged 'spool/sync.' directory?

--On 22 November 2016 23:08 +1100 Bron Gondwana via Cyrus-devel wrote: Yes, it's definitely safe to delete wheneven the server is shut down. We remove it as part of the startup script at FastMail, just in case something crashed. Both sync_server and

Safe to delete apparently stale / aged 'spool/sync.' directory?

Hi, We've upgraded a number of Cyrus servers through the years - we're currently running 2.5.x. The other day I noticed on a couple of servers we have: /vol/imap/spool/sync. This directory hasn't been touched in years - but has a number of sub-dirs (all numbers) - that all contain

Re: Cyrus 2.5.7 idled not stopped when server shut down?

--On 16 September 2016 14:12 +1000 ellie timoney via Cyrus-devel wrote: The attached patch seems to resolve this for me. Karl, does it help in your case? It's against the current cyrus-imapd-2.5 from git, but should apply cleanly to the 2.5.7 sources as

Cyrus 2.5.7 idled not stopped when server shut down?

Hi, We're in the process of moving from Cyrus 2.4.17 to 2.5.7. So far this is going OK - but I've noticed when I stop the 2.5.7 server (this is on FreeBSD so 'service imapd stop') - it leaves behind idled? Should this be stopped by the imap server itself, or does it need stopping manually

Re: 2.5.7 -> 2.5.7 initial replication fails - failed to parse?

--On 20 April 2016 13:15 -0400 Giles Malet wrote: I can't answer your other questions, but deleting those directories is fine. The only one(s) possible in use are those whose name matches the PID of a running sync_server process. Perhaps best then to shut cyrus down on

Re: 2.5.7 -> 2.5.7 initial replication fails - failed to parse?

--On 20 April 2016 at 13:15:24 -0400 Giles Malet wrote: Can I safely remove all of '/sync./*' and start the replication again? - I had a bit of fun & games getting some 2.5.7 servers up (upgraded from 2.4), and ended up doing a few `reconstruct -rfGO' runs on them,

2.5.7 -> 2.5.7 initial replication fails - failed to parse?

Hi, I have 2 * 2.5.7 servers. The first is setup to replicate to the other (which is currently empty). The 'master' has quite a bit of mail on it (~90Gb). As it's quite a lot - I brought up the replica, but left 'rolling' replication off. On the 'master' I then ran:

Re: Replication between versions 2.5.7 and 2.4.17?

--On 12 April 2016 11:00 -0400 Giles Malet wrote: The 2.4.17 server has a partner it replicates to. If we update the main server to 2.5.7 - is this still able to replicate to it's 2.4.17 partner? Although this doesn't really answer your question, we did the reverse,

Replication between versions 2.5.7 and 2.4.17?

Hi, We have a Cyrus-IMAP server, v2.4.17 - which we're about to do an "in place" upgrade (i.e. keep the data, re-install newer version of OS + Cyrus IMAP). In testing this seems to work out OK (once the new server is run up, database files etc. are 'in place' upgrade as they're found - or

Re: inefficient replication / SYNCERROR: only exists on replica

--On 20 July 2013 11:36 +1000 Bron Gondwana br...@fastmail.fm wrote: I would recommend running cyr_expire with -a (skip annotation) on the replica to avoid this. Hi, thanks for the reply - to clarify, *just* '-a' on the replica, or should we mirror the '-X 3 -D 3 -E 3' as well as '-a' on

Re: Sync after replica restarted...

--On 17 July 2013 16:48:24 +0200 Michael Menge michael.me...@zdv.uni-tuebingen.de wrote: Bevor you run sync_client -r you should run sync_client -r -f /PATH_TO_SYNC_DIR/log-33213 to sync what was left form the old sync process and confirm that the exit code is 0 (echo $?) than you can

Sync after replica restarted...

Hi, We have our pair of 2.4.17 servers running quite nicely. I had to re-start the replica server this morning, and the master has this logged: Jul 17 10:36:17 sync_client[33213]: COMPRESS received NO response: Compression already active: DEFLATE Jul 17 10:36:17 sync_client[33213]: Failed

Re: Expunged mail files left 'on disk'?

--On 9 July 2013 19:44:19 +1000 Bron Gondwana br...@fastmail.fm wrote: Back on list - one issue that can cause cleanups to fail on 2.4.x is an ongoing connection to the mailbox. If another process is holding the mailbox name lock, then the cleanup is left for that process to finish instead.

Re: Expunged mail files left 'on disk'?

--On 05 July 2013 12:20 +0200 Sebastian Hagedorn haged...@uni-koeln.de wrote: No. So I'm guessing that your delete_mode actually isn't immediate. There's no harm in using cyr_expire with the additional flags, but you could also add delete_mode: immediate to your imapd.conf if you want to be

Re: Expunged mail files left 'on disk'?

--On 05 July 2013 12:20 +0200 Sebastian Hagedorn haged...@uni-koeln.de wrote: From the manpage: -X expunge-duration Expunge previously deleted messages older than expunge-duration (when using the delayed expunge mode). Format is the same as

Expunged mail files left 'on disk'?

Hi, I just noticed on our cyrus-imap server (2.4.17) - a users mail box had 3 messages in it (according to their IMAP client) - yet on disk (in their spool/user directory) there were around a thousand message files, i.e. 172382. 172381. 172392. etc - going back about two weeks. Should

Re: Sieve with plussed delivery / 'seen flag'?

--On 30 June 2013 18:52 +0200 Дилян Палаузов dilyan.palau...@aegee.org wrote: Hello, this is similar to Bug 3695 ( https://bugzilla.cyrusimap.org/show_bug.cgi?id=3695 ). Hi, Thanks for the reply! - That bug kinda looks similar - more importantly, the 'workaround' of using an extra

Sieve with plussed delivery / 'seen flag'?

Hi, We're running Cyrus IMAP 2.4.17. We've got sieve rules used for accounts - and some users use 'plussed' addresses. For example, I've setup a Sieve rule that matches on a subject of 'Test': require [fileinto]; require [imapflags]; if header :contains [Subject] [Test] { addflag \\Seen;

Sharing mailbox between 'login accounts' - i.e. for remote devices...

Hi, On our IMAP server we have a shared folder, accessed by a number of the IT support team. At the moment we've setup separate 'unix' accounts for these people - e.g. 'tech1', 'tech2', 'tech3' - and then given them rights to the mailbox 'technical'. However, this means they all

Re: Sharing mailbox between 'login accounts' - i.e. for remote devices...

--On 18 June 2013 08:20 -0500 Dan White dwh...@olp.net wrote: Another simpler approach would be to have your users login with an authz identity if your software supports it. Sorry, how do you mean? - With an authorization ID? Thanks, -Karl

Re: Sharing mailbox between 'login accounts' - i.e. for remote devices...

--On 18 June 2013 17:10 +0200 Rudy Gevaert rudy.geva...@ugent.be wrote: As far as I know only the mulberry client supports it. And almost nobody uses it. Before some years it was even proprietary software. See http://www.mulberrymail.com/ Hehe, I know of Mulberry :) In my case I have

sync_client fails with GSSAPI error 'unknown mech-code 0 for mech unknown'

Hi, I've got my two 2.4.17 servers 'tantalisingly' close to replicating - I created a 'replication' user on both (using 'saslpasswd2'). This user is allowed 'admin' access (in imapd.conf). Additionally on the master I've set: sync_host: my-replica-server.com sync_authname:

Re: 'Upgrade' from Cyrus 2.3.18 to 2.4.17 - need to rebuild '.seen' files?

Further to my original post... If I run imapd up - and access the mailbox, I see the following logged: May 31 10:44:20 imaps[7401]: seen_db: user fred opened /vol/host/imap/user/f/fred.seen May 31 10:44:20 imaps[7401]: Index upgrade: user.fred (10 - 12) May 31 10:44:20 imaps[7401]: open:

'Upgrade' from Cyrus 2.3.18 to 2.4.17 - need to rebuild '.seen' files?

Hi, I've just built a new Cyrus IMAP server (2.4.17) under FreeBSD - and 'moved' our mail store across. Before starting imapd - I then rebuilt/checked the databases with: % /usr/local/cyrus/bin/ctl_cyrusdb -r According to syslog this went ok. However, I can't run reconstruct - it just

Re: Replication documentation anywhere?

--On 24 May 2013 11:10 +1000 Bron Gondwana br...@fastmail.fm wrote: I'm afraid there isn't much :( Feel free to ask questions about specific things you run in to, and we can use that as a basis to put together more detailed documentation. Hi, Thanks for your reply (which I've read through

Replication documentation anywhere?

Hi, We're running cyrus-imapd-2.4.17 on FreeBSD. I've been looking at the replication built into Cyrus, but can't find much (if any) documentation on it. e.g. The shipped 'install-replication.html' file ends at: ... You can also run cyr_synclog(8) instead, which will insert the record

Weird path appearing in skiplist checkpointing?

Hi, We're currently running Cyrus IMAP 2.3.18 on FreeBSD 7.x amd64, on a machine with ECC and ZFS as the backing store (this machine has been in service for quite a while - through a number of IMAPd upgrades). No drive, memory or ZFS errors are logged. Recently, a couple of users have