Newly arrived mail is marked as "read"
I'm in the process of testing the upgrade from a CentOS 6 box running 2.3.16 to a CentOS 8 box running 3.0.7. The upgrade has been less troublesome than expected, but I'm seeing a strange problem with newly received mail being marked as "read" even though they have not been opened by the client. This is the case for both mail sent locally as well as mail received externally (Gmail). Can anyone point me in the right direction on where to look to fix this? Thanks. Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: DB4 downgrade
Simon Matter wrote: Simon Matter wrote: Because of the sudden end-of-life of Fedora Core 4, I'm moving my mail server from FC4 to a CentOS 4.4 box. FC4 uses DB4 4.3.27. CentOS 4.4 uses DB4 4.2.52. What's the best way for me to downgrade the Cyrus DBs for this migration? Convert all BerkeleyDBs on the FC4 box to skiplist and then migrate to the new server/installation. Skiplist doesn't change from version to version so you don't have that problem anymore. Sounds good. It's sufficient just to use the file command to see which of the db files are already skiplist and which are Berkeley DB? Yes, that should be okay. For me it looks like this: [EMAIL PROTECTED] imap]# file /var/lib/imap/*.db /var/lib/imap/annotations.db: Cyrus skiplist DB /var/lib/imap/deliver.db: Cyrus skiplist DB /var/lib/imap/mailboxes.db:Cyrus skiplist DB /var/lib/imap/tls_sessions.db: Cyrus skiplist DB One more tip: You may want to remove all data from the db dirs because there may still be some files from the BerkeleyDB and they can lead to error messages, which are in fact not real cyrus errors. On such a migratin I usually do this after rsyncing: rm -rvf /var/lib/imap/db/* /var/lib/imap/db.* I finally got a window of scheduled downtime to test this, and I'm having problems. Here's what I did: # /etc/init.d/cyrus-imapd stop # db_checkpoint -v -1 -h /var/lib/imap/db # db_recover -v -h /var/lib/imap/db # rm db/* # /usr/lib/cyrus-imapd/cvt_cyrusdb /var/lib/imap/deliver.db berkeley /var/lib/imap/deliver.db.skip skiplist # /usr/lib/cyrus-imapd/cvt_cyrusdb /var/lib/imap/tls_sessions.db berkeley /var/lib/imap/tls_sessions.db.skip skiplist # mv deliver.db.skip deliver.db ; mv tls_sessions.db.skip tls_sessions.db # chown cyrus:mail tls_sessions.db deliver.db # /etc/init.d/cyrus-imapd start At this point, the log explodes with messages along the lines of: Dec 11 06:11:53 ajax imaps[1394]: DBERROR: critical database situation Dec 11 06:11:53 ajax master[32203]: service imaps pid 1394 in READY state: terminated abnormally Dec 11 06:11:53 ajax master[32203]: service lmtpunix pid 1397 in READY state: terminated abnormally Dec 11 06:11:53 ajax imap[1395]: DBERROR A : db4 Dec 11 06:11:53 ajax imap[1395]: DBERROR: critical database situation Dec 11 06:11:53 ajax master[32203]: service imap pid 1395 in READY state: terminated abnormally Dec 11 06:11:53 ajax imap[1399]: DBERROR A : db4 Dec 11 06:11:53 ajax imap[1399]: DBERROR: critical database situation Dec 11 06:11:53 ajax imaps[1400]: DBERROR A : db4 Dec 11 06:11:53 ajax imaps[1400]: DBERROR: critical database situation Any ideas on why this is going on? I did notice that /var/lib/imap/rpm/db.cfg.cache has entries along the lines of: CONFIG_DB_DUPLICATE=berkeley CONFIG_DB_MBOX=skiplist CONFIG_DB_SEEN=skiplist CONFIG_DB_SUBS=flat CONFIG_DB_TLS=berkeley CONFIG_DB_ANNOTATION=skiplist CONFIG_DB_SIEVE=2.2.3 Is there someplace I need to tell imapd that deliver and tls_sessions are now skiplist? I don't see anything in /etc/imapd.conf and /etc/cyrus.conf. Thanks. Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: DB4 downgrade
Simon Matter wrote: I finally got a window of scheduled downtime to test this, and I'm having problems. Here's what I did: # /etc/init.d/cyrus-imapd stop # db_checkpoint -v -1 -h /var/lib/imap/db # db_recover -v -h /var/lib/imap/db # rm db/* # /usr/lib/cyrus-imapd/cvt_cyrusdb /var/lib/imap/deliver.db berkeley /var/lib/imap/deliver.db.skip skiplist # /usr/lib/cyrus-imapd/cvt_cyrusdb /var/lib/imap/tls_sessions.db berkeley /var/lib/imap/tls_sessions.db.skip skiplist # mv deliver.db.skip deliver.db ; mv tls_sessions.db.skip tls_sessions.db # chown cyrus:mail tls_sessions.db deliver.db # /etc/init.d/cyrus-imapd start At this point, the log explodes with messages along the lines of: Dec 11 06:11:53 ajax imaps[1394]: DBERROR: critical database situation Dec 11 06:11:53 ajax master[32203]: service imaps pid 1394 in READY state: terminated abnormally Dec 11 06:11:53 ajax master[32203]: service lmtpunix pid 1397 in READY state: terminated abnormally Dec 11 06:11:53 ajax imap[1395]: DBERROR A : db4 Dec 11 06:11:53 ajax imap[1395]: DBERROR: critical database situation Dec 11 06:11:53 ajax master[32203]: service imap pid 1395 in READY state: terminated abnormally Dec 11 06:11:53 ajax imap[1399]: DBERROR A : db4 Dec 11 06:11:53 ajax imap[1399]: DBERROR: critical database situation Dec 11 06:11:53 ajax imaps[1400]: DBERROR A : db4 Dec 11 06:11:53 ajax imaps[1400]: DBERROR: critical database situation Any ideas on why this is going on? I did notice that /var/lib/imap/rpm/db.cfg.cache has entries along the lines of: CONFIG_DB_DUPLICATE=berkeley CONFIG_DB_MBOX=skiplist CONFIG_DB_SEEN=skiplist CONFIG_DB_SUBS=flat CONFIG_DB_TLS=berkeley CONFIG_DB_ANNOTATION=skiplist CONFIG_DB_SIEVE=2.2.3 Is there someplace I need to tell imapd that deliver and tls_sessions are now skiplist? I don't see anything in /etc/imapd.conf and /etc/cyrus.conf. Something is really broken here... First shutdown using 'service cyrus-imapd stop', then put this in /etc/imapd.conf: duplicate_db: skiplist tlscache_db: skiplist Now try to start it up using 'service cyrus-imapd start'. Unfortunately I think the cyrus-imapd package shipped with FC4 has some bugs in the init scripts. I recommend you use my rpms, which are newer and have less bugs. RedHat ships old versions of my rpms which don't include the latest bug fixes. Find the source rpm here: http://www.invoca.ch/pub/packages/cyrus-imapd/ I tried what you suggested regarding just the /etc/imapd.conf changes, but without using your RPMs. There was no change: DBERROR messages everywhere until the imapd service was stopped, etc. I will try using your RPMs during the next period of scheduled maintenance, later this week. Thanks again. Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
DB4 downgrade
Because of the sudden end-of-life of Fedora Core 4, I'm moving my mail server from FC4 to a CentOS 4.4 box. FC4 uses DB4 4.3.27. CentOS 4.4 uses DB4 4.2.52. What's the best way for me to downgrade the Cyrus DBs for this migration? Thanks. Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: DB4 downgrade
Simon Matter wrote: Because of the sudden end-of-life of Fedora Core 4, I'm moving my mail server from FC4 to a CentOS 4.4 box. FC4 uses DB4 4.3.27. CentOS 4.4 uses DB4 4.2.52. What's the best way for me to downgrade the Cyrus DBs for this migration? Convert all BerkeleyDBs on the FC4 box to skiplist and then migrate to the new server/installation. Skiplist doesn't change from version to version so you don't have that problem anymore. Sounds good. It's sufficient just to use the file command to see which of the db files are already skiplist and which are Berkeley DB? Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
timsieved problem with parsing scripts
We're running Cyrus IMAPD 2.2.3 from Fedora Core 2 and we're having problems with timsieved in terms of it parsing scripts into bytecode. When using sieveshell on the following trivial script, we're getting the following error: # more testsieve redirect [EMAIL PROTECTED]; # sieveshell --user=myuser --authname=myuser localhost connecting to localhost Please enter your password: put testsieve upload failed: put script: script errors: line 1: parse error, unexpected IF, expecting ';' We have similar errors for any valid script we've tried to load using sieveshell connecting to timsieved. On the other hand, using sievec, we are able to compile these scripts without error. Does anyone have any idea what's going on? Thanks. --- 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
