signal 11 - it was really the kernel
Hi, I have spent two days to get cyrus-imapd working. I have tried everything, but I was getting signal 11, from 1 to 5 per hour, so it was impossible to use it. After searching I found in faq, that it could be caused by kernel 2.4.17. So I moved to 2.4.18, and ..., it works now 6 hours with no problems. As it was rather hard to find it, it would be nice, if included on main cyrus-imapd page, or at least in: Installation Frequently Asked Questions or Linux Cyrus HOWTO Thanks to that guy, who found it! Regards, Olaf Fr?czyk
Want sieve but don't want delivery duplicate supression
Hi, Any hope to get it working? It makes trouble, especially with mailing lists. Eg. somebody posted mail to group1,group2, and to me. In result I see only one message. But I have filter in sieve, so it sorts mail into different folders. So in my inbox is no message, only in folder for group1. As I don't have time to look for messages in group1, I would like to have it in my inbox, so I know that somebody posted a message to me, and I have to reply on it. Will it be possible in next imapd version: 2.1? Regards, Olaf Fraczyk
Do I need user prefix for all mail folders, eg. user.olaf ?
Hi, I want to have some shared folders in my company. Do I have to add a dummy user and build folder structure under it or I may have mailboxes like that: office.subject1 office.subject2 info.subject1 etc.? Will it break something? Mail to these boxes would be put using sieve. Regards, Olaf Fraczyk
Sieve doesn't catch all messages it should
Hi,
Sieve doesn't catch all messages. It is probably caused , by a little
malformed header,
but with procmail I hadn't those problems.
I include header for message that is catched, and for this is not.
I think that it is ">" character before one of "Received:".
Anyway I think it's sieve's fault.
Regards,
Olaf Fraczyk
Here is the rule for sieve:
if header :contains "Sender" "[EMAIL PROTECTED]" {
fileinto "user.olaf.xfs";
}
Message header that is not catched:
Return-Path: <[EMAIL PROTECTED]>
X-Sieve: cmu-sieve 2.0
Received: from localhost (localhost.localdomain [127.0.0.1])
by venus.local.navi.pl (8.11.6/8.11.6) with ESMTP id g2580Be02570
for ; Tue, 5 Mar 2002 09:00:11 +0100
Received: from 150.254.173.27
by localhost with POP3 (fetchmail-5.9.0)
for olaf@localhost (single-drop); Tue, 05 Mar 2002 09:00:11 +0100
(CET)
Received: from oss.sgi.com (oss.sgi.com [216.32.174.27])
by cbk.poznan.pl (8.9.2/8.9.2) with ESMTP id HAA26959
for <[EMAIL PROTECTED]>; Tue, 5 Mar 2002 07:49:27 GMT
Received: from localhost (mail@localhost)
by oss.sgi.com (8.11.2/8.11.3) with SMTP id g258mOL16091;
Tue, 5 Mar 2002 00:48:24 -0800
X-Authentication-Warning: oss.sgi.com: mail owned process doing -bs
Received: by oss.sgi.com (bulk_mailer v1.13); Tue, 5 Mar 2002 00:48:22
-0800
Received: (from majordomo@localhost)
by oss.sgi.com (8.11.2/8.11.3) id g258mMf16060
for linux-xfs-outgoing; Tue, 5 Mar 2002 00:48:22 -0800
Received: from mx.de.kpnqwest.net (mx.de.kpnqwest.net [193.141.40.5])
by oss.sgi.com (8.11.2/8.11.3) with SMTP id g258mE916033
for <[EMAIL PROTECTED]>; Tue, 5 Mar 2002 00:48:14 -0800
Received: from lizard.webland.de (unknown [194.122.76.106])
by mx.de.kpnqwest.net (Postfix (mx07)) with ESMTP
id 7BF226128; Tue, 5 Mar 2002 08:48:08 +0100 (MET)
(envelope-from [EMAIL PROTECTED])
Received: (from uucp@localhost)
by lizard.webland.de (8.8.8/8.8.7) id IAA27968;
Tue, 5 Mar 2002 08:48:07 +0100 (MET)
> Received: from mobile.sauter-bc.com (unknown [10.1.6.21])
by basel1.sauter-bc.com (Postfix) with ESMTP
id 3BF7357306; Tue, 5 Mar 2002 08:48:02 +0100 (CET)
Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117])
by mobile.sauter-bc.com (Postfix) with ESMTP
id 1C6CB25835; Tue, 5 Mar 2002 08:48:02 +0100 (CET)
Message-ID: <[EMAIL PROTECTED]>
Date: Tue, 05 Mar 2002 08:48:02 +0100
From: Simon Matter <[EMAIL PROTECTED]>
Organization: Sauter AG, Basel
X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.12 i686)
X-Accept-Language: de-CH, en
MIME-Version: 1.0
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: Million files or so on RAID 5 Partition
References: <[EMAIL PROTECTED]>
Content-Transfer-Encoding: 7bit
Sender: [EMAIL PROTECTED]
Precedence: bulk
Content-Type: text/plain; charset=us-ascii
Message header that is catched:
Return-Path: <[EMAIL PROTECTED]>
X-Sieve: cmu-sieve 2.0
Received: from localhost (localhost.localdomain [127.0.0.1])
by venus.local.navi.pl (8.11.6/8.11.6) with ESMTP id g2580De02573
for ; Tue, 5 Mar 2002 09:00:13 +0100
Received: from 150.254.173.27
by localhost with POP3 (fetchmail-5.9.0)
for olaf@localhost (single-drop); Tue, 05 Mar 2002 09:00:13 +0100
(CET)
Received: from oss.sgi.com (oss.sgi.com [216.32.174.27])
by cbk.poznan.pl (8.9.2/8.9.2) with ESMTP id HAA26967
for <[EMAIL PROTECTED]>; Tue, 5 Mar 2002 07:52:42 GMT
Received: from localhost (mail@localhost)
by oss.sgi.com (8.11.2/8.11.3) with SMTP id g258piE16251;
Tue, 5 Mar 2002 00:51:44 -0800
X-Authentication-Warning: oss.sgi.com: mail owned process doing -bs
Received: by oss.sgi.com (bulk_mailer v1.13); Tue, 5 Mar 2002 00:51:41
-0800
Received: (from majordomo@localhost)
by oss.sgi.com (8.11.2/8.11.3) id g258pf716220
for linux-xfs-outgoing; Tue, 5 Mar 2002 00:51:41 -0800
Received: from cellus.no (www.smsiden.com [193.91.191.71] (may be forged))
by oss.sgi.com (8.11.2/8.11.3) with SMTP id g258pZ916197
for <[EMAIL PROTECTED]>; Tue, 5 Mar 2002 00:51:35 -0800
Received: from christian ([193.69.127.56])
by cellus.no (8.9.3/8.9.3) with SMTP id IAA07693;
Tue, 5 Mar 2002 08:51:23 +0100
From: =?iso-8859-1?Q?Christian_R=F8snes?= <[EMAIL PROTECTED]>
To: "Austin Gonyou" <[EMAIL PROTECTED]>
Cc: "Keith Owens" <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>
Subject: RE: Linux 2.4.18 freeze running dbench 1.3
Date: Tue, 5 Mar 2002 08:51:27 +0100
Message-ID: <[EMAIL PROTECTED]>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <1015287386.24622.3.camel@UberGeek>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.
Importance: Normal
Sender: [EMAIL PROTECTED]
Precedence: bulk
Content-Type: text/plain;
charset="iso-
cyradm not showing metadata if logged as admin
Hello,
cyrus-imapd-2.5.10-2.3.el7.x86_64 from open build system
I have set metadata for mailboxes:
t3 SETMETADATA "INBOX/Sent" (/private/specialuse "\\Sent")
I can see the metadata from imap connection and from cyradm but only
when logged as user:
t3 LIST (SPECIAL-USE) "" "*"
* LIST (\HasNoChildren \Drafts) "/" INBOX/Drafts
* LIST (\HasNoChildren \Sent) "/" INBOX/Sent
* LIST (\HasNoChildren \Trash) "/" INBOX/Trash
* LIST (\HasNoChildren \Junk) "/" INBOX/spam
192.168.1.8> getmd INBOX/Sent
{INBOX/Sent}:
private:
check: NIL
checkperiod: NIL
comment: NIL
sort: NIL
specialuse: \Sent
thread: NIL
expire: NIL
news2mail: NIL
sieve: NIL
squat: NIL
When logged as cyrus admin I get:
192.168.1.8> getmd user/info/s...@navi.pl
{user/info/s...@navi.pl}:
private:
check: NIL
checkperiod: NIL
comment: NIL
sort: NIL
specialuse: NIL
thread: NIL
expire: NIL
news2mail: NIL
sieve: NIL
squat: NIL
I want to be able to set the metadata for users' mailboxes, so the
Outlook and Thunderbird use correct folders.
I tried to give the admin full ACL rights for this mailbox but it didn't
help.
Is there any configuration option to change this behaviour?
Best regards,
Olaf Frączyk
--
NAVI Sp. z o.o.
Promienista 5/1
60-288 Poznań
mobile: +48609769035
phone: +48616622881
fax: +48616622882
http://www.navi.pl
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
Set metadata (specialuse - Sent,Junk,Drafts) as admin for other user
Hello, Is there any possibility to set metadata for a users mailbox? I need to set specialuse, so the users use correct folders for sent, drafts,junk. As the users use different mail clients in different language versions, they have a mess in their folders. Eg. Outlook 2013 Polish and English and Thunderbird Polish and English it is impossible to use the same folders. As it is impossible to set others' users private/specialuse as admin, I tried shared/specialuse but I got "permission denied" both for admin and for user. Is it possible to impersonate admin as a user (not using user's password)? Or maybe there is some other way to accomplish my goal? I cannot expect from users to login via telnet and set it by themselves. Best regards, Olaf Frączyk -- NAVI Sp. z o.o. Promienista 5/1 60-288 Poznań mobile: +48609769035 phone: +48616622881 fax: +48616622882 http://www.navi.pl 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
Replication - current status and how to do failover
Hello, 1. Is currently master-master replication possible (maybe 3.2) Is it OK to sync them two-way? If yes - how to set up such config? 2. If master-master is impossible, is there any guide how to setup failover from master to slave and possibly back? If split-brain happens - is there an easy recovery from such state? Best regards, Olaf 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
Replication failed 3.0.5 -> 3.0.13
Hi, I'm running 3.0.5. I want to migrate to a new machine. I set up cyrus-imapd 3.0.13. The replication started but it didn't transfer all mails. The store isn't big 44GB, transferred was about 24 GB. In the logs I see: Apr 20 14:54:03 ifs sync_client[24239]: couldn't authenticate to backend server: authentication failure Apr 20 14:54:13 ifs sync_client[24239]: connect(skink1.navi.pl) failed: Connection timed out Apr 20 14:58:13 ifs sync_client[24239]: auditlog: proxy sessionid= remote= Apr 20 15:12:41 ifs sync_client[24239]: sync_client RESTART succeeded Apr 20 15:12:42 ifs sync_client[24239]: auditlog: proxy sessionid= remote= Apr 20 15:12:46 ifs sync_client[24239]: inefficient replication (39865 > 48) navi.pl!user.info Apr 20 15:15:31 ifs sync_client[24239]: inefficient replication (32058 > 56) navi.pl!user.olaf Apr 20 15:18:50 ifs sync_client[24239]: inefficient replication (15216 > 13867) navi.pl!user.ania Apr 20 15:19:18 ifs sync_client[24239]: inefficient replication (56949 > 432) navi.pl!user.piotr Apr 20 15:25:11 ifs sync_client[24239]: sync_client RESTART succeeded Apr 20 15:25:12 ifs sync_client[24239]: auditlog: proxy sessionid= remote= Apr 20 15:29:09 ifs sync_client[24239]: IOERROR: zero length response to MAILBOXES (idle for too long) Apr 20 15:29:09 ifs sync_client[24239]: IOERROR: zero length response to RESTART (idle for too long) Apr 20 15:29:09 ifs sync_client[24239]: Error in do_sync(): bailing out! Bad protocol Apr 20 15:29:09 ifs sync_client[24239]: Processing sync log file /var/lib/imap/sync/log-run failed: Bad protocol I also executed thereafter sync client manually: /usr/local/cyrus-3.0.5/sbin/sync_client -r but nothing changed, in the log appeared: Apr 20 15:37:23 ifs sync_client[27304]: Reprocessing sync log file /var/lib/imap/sync/log-run The directory /var/lib/imap/sync/ on master is empty. The directory /var/spool/imap/sync. on replica is also empty What can I try to get it woring? Is there a serious problem with replication in 3.0.5? I wanted to avoid upgrade on the old machine. Best regrads, Olaf Frączyk 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: Replication failed 3.0.5 -> 3.0.13, now 3.0.13->3.0.13
Hi, I upgraded to 3.0.13 but it didn't help. This time it copied about 18GB in the logs I still see: 1 - inefficient replication 2 - IOERROR: zero length response to MAILBOXES (idle for too long) IOERROR: zero length response to RESTART (idle for too long) Error in do_sync(): bailing out! Bad protocol But I have no idea what can I do next and why it fails Apr 21 02:24:46 ifs sync_client[12656]: IOERROR: zero length response to MAILBOXES (idle for too long) Apr 21 02:24:46 ifs sync_client[12656]: IOERROR: zero length response to RESTART (idle for too long) Apr 21 02:24:46 ifs sync_client[12656]: Error in do_sync(): bailing out! Bad protocol Apr 21 02:24:46 ifs sync_client[12656]: Processing sync log file /var/lib/imap/sync/log-run failed: Bad protocol Apr 21 03:46:10 ifs sync_client[1353]: auditlog: proxy sessionid= remote= Apr 21 03:53:15 ifs sync_client[1353]: inefficient replication (32058 > 56) navi.pl!user.olaf Apr 21 03:59:41 ifs sync_client[1353]: sync_client RESTART succeeded Apr 21 03:59:41 ifs sync_client[1353]: auditlog: proxy sessionid= remote= Apr 21 04:01:49 ifs sync_client[1353]: inefficient replication (56949 > 432) navi.pl!user.piotr Apr 21 04:10:38 ifs sync_client[1353]: sync_client RESTART succeeded Apr 21 04:10:38 ifs sync_client[1353]: auditlog: proxy sessionid= remote= Apr 21 04:20:39 ifs sync_client[1353]: sync_client RESTART succeeded Apr 21 04:20:39 ifs sync_client[1353]: auditlog: proxy sessionid= remote= Apr 21 04:30:34 ifs sync_client[1353]: IOERROR: zero length response to MAILBOXES (idle for too long) Apr 21 04:30:34 ifs sync_client[1353]: IOERROR: zero length response to RESTART (idle for too long) Apr 21 04:30:34 ifs sync_client[1353]: Error in do_sync(): bailing out! Bad protocol Regards, Olaf On 2020-04-20 16:11, Olaf Frączyk wrote: Hi, I'm running 3.0.5. I want to migrate to a new machine. I set up cyrus-imapd 3.0.13. The replication started but it didn't transfer all mails. The store isn't big 44GB, transferred was about 24 GB. In the logs I see: Apr 20 14:54:03 ifs sync_client[24239]: couldn't authenticate to backend server: authentication failure Apr 20 14:54:13 ifs sync_client[24239]: connect(skink1.navi.pl) failed: Connection timed out Apr 20 14:58:13 ifs sync_client[24239]: auditlog: proxy sessionid= remote= Apr 20 15:12:41 ifs sync_client[24239]: sync_client RESTART succeeded Apr 20 15:12:42 ifs sync_client[24239]: auditlog: proxy sessionid= remote= Apr 20 15:12:46 ifs sync_client[24239]: inefficient replication (39865 > 48) navi.pl!user.info Apr 20 15:15:31 ifs sync_client[24239]: inefficient replication (32058 > 56) navi.pl!user.olaf Apr 20 15:18:50 ifs sync_client[24239]: inefficient replication (15216 > 13867) navi.pl!user.ania Apr 20 15:19:18 ifs sync_client[24239]: inefficient replication (56949 > 432) navi.pl!user.piotr Apr 20 15:25:11 ifs sync_client[24239]: sync_client RESTART succeeded Apr 20 15:25:12 ifs sync_client[24239]: auditlog: proxy sessionid= remote= Apr 20 15:29:09 ifs sync_client[24239]: IOERROR: zero length response to MAILBOXES (idle for too long) Apr 20 15:29:09 ifs sync_client[24239]: IOERROR: zero length response to RESTART (idle for too long) Apr 20 15:29:09 ifs sync_client[24239]: Error in do_sync(): bailing out! Bad protocol Apr 20 15:29:09 ifs sync_client[24239]: Processing sync log file /var/lib/imap/sync/log-run failed: Bad protocol I also executed thereafter sync client manually: /usr/local/cyrus-3.0.5/sbin/sync_client -r but nothing changed, in the log appeared: Apr 20 15:37:23 ifs sync_client[27304]: Reprocessing sync log file /var/lib/imap/sync/log-run The directory /var/lib/imap/sync/ on master is empty. The directory /var/spool/imap/sync. on replica is also empty What can I try to get it woring? Is there a serious problem with replication in 3.0.5? I wanted to avoid upgrade on the old machine. Best regrads, Olaf Frączyk 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 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: Replication failed 3.0.5 -> 3.0.13, now 3.0.13->3.0.13
Hi, When I run sync_client -r on the master I see the following on the replica: Apr 21 10:56:15 skink1 imap[5775]: mailbox: longlock navi.pl!user.olaf for 1.7 seconds Apr 21 10:56:20 skink1 imap[5775]: mailbox: longlock navi.pl!user.piotr for 2.0 seconds Apr 21 10:56:23 skink1 imap[5775]: mailbox: longlock navi.pl!user.olaf for 2.9 seconds Apr 21 10:56:26 skink1 imap[5775]: mailbox: longlock navi.pl!user.piotr for 3.0 seconds The mailboxes have several GB in Inbox folder and several GB in subfolders. The inbox folders have about 20,000 messages, the subfolders upto 15,000 Could it cause problems? Maybe I should move the sync_client from START section to SERVICES, it seems that it is not automatically restarted On 2020-04-21 08:47, Michael Menge wrote: Hi Olaf Quoting Olaf Frączyk : Hi, I upgraded to 3.0.13 but it didn't help. This time it copied about 18GB in the logs I still see: 1 - inefficient replication 2 - IOERROR: zero length response to MAILBOXES (idle for too long) IOERROR: zero length response to RESTART (idle for too long) Error in do_sync(): bailing out! Bad protocol But I have no idea what can I do next and why it fails Apr 21 02:24:46 ifs sync_client[12656]: IOERROR: zero length response to MAILBOXES (idle for too long) Apr 21 02:24:46 ifs sync_client[12656]: IOERROR: zero length response to RESTART (idle for too long) Apr 21 02:24:46 ifs sync_client[12656]: Error in do_sync(): bailing out! Bad protocol do you see any errors on the syncserver side. The error look like the sync_client is waiting for a reply of the server. M.Menge Tel.: (49) 7071/29-70316 Universität Tübingen Fax.: (49) 7071/29-5912 Zentrum für Datenverarbeitung mail: michael.me...@zdv.uni-tuebingen.de Wächterstraße 76 72074 Tübingen 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 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: Replication failed 3.0.5 -> 3.0.13, now 3.0.13->3.0.13
I also found out that when I see on master: Apr 21 11:12:38 ifs sync_client[27996]: IOERROR: zero length response to MAILBOXES (idle for too long) Apr 21 11:12:38 ifs sync_client[27996]: IOERROR: zero length response to RESTART (idle for too long) Apr 21 11:12:38 ifs sync_client[27996]: Error in do_sync(): bailing out! Bad protocol Apr 21 11:12:38 ifs sync_client[27996]: Processing sync log file /var/lib/imap/sync/log-run failed: Bad protocol I also get on the replica: Apr 21 11:12:38 skink1 imap[5775]: Connection reset by peer, closing connection But I also see, that before it happens, there is no activity both on the replica and on the master for some time. So maybe the imap server process is not recovering correctly in the longlock situation? On 2020-04-21 11:07, Olaf Frączyk wrote: Hi, When I run sync_client -r on the master I see the following on the replica: Apr 21 10:56:15 skink1 imap[5775]: mailbox: longlock navi.pl!user.olaf for 1.7 seconds Apr 21 10:56:20 skink1 imap[5775]: mailbox: longlock navi.pl!user.piotr for 2.0 seconds Apr 21 10:56:23 skink1 imap[5775]: mailbox: longlock navi.pl!user.olaf for 2.9 seconds Apr 21 10:56:26 skink1 imap[5775]: mailbox: longlock navi.pl!user.piotr for 3.0 seconds The mailboxes have several GB in Inbox folder and several GB in subfolders. The inbox folders have about 20,000 messages, the subfolders upto 15,000 Could it cause problems? Maybe I should move the sync_client from START section to SERVICES, it seems that it is not automatically restarted On 2020-04-21 08:47, Michael Menge wrote: Hi Olaf Quoting Olaf Frączyk : Hi, I upgraded to 3.0.13 but it didn't help. This time it copied about 18GB in the logs I still see: 1 - inefficient replication 2 - IOERROR: zero length response to MAILBOXES (idle for too long) IOERROR: zero length response to RESTART (idle for too long) Error in do_sync(): bailing out! Bad protocol But I have no idea what can I do next and why it fails Apr 21 02:24:46 ifs sync_client[12656]: IOERROR: zero length response to MAILBOXES (idle for too long) Apr 21 02:24:46 ifs sync_client[12656]: IOERROR: zero length response to RESTART (idle for too long) Apr 21 02:24:46 ifs sync_client[12656]: Error in do_sync(): bailing out! Bad protocol do you see any errors on the syncserver side. The error look like the sync_client is waiting for a reply of the server. M.Menge Tel.: (49) 7071/29-70316 Universität Tübingen Fax.: (49) 7071/29-5912 Zentrum für Datenverarbeitung mail: michael.me...@zdv.uni-tuebingen.de Wächterstraße 76 72074 Tübingen 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 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 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: Replication failed 3.0.5 -> 3.0.13, now 3.0.13->3.0.13
The current situation is: 1. Replica: stopped and started the replica no activity on replica - iotop and top show nothing the only messages on replica is incoming connection from master 2. Master: when I run sync_client -r I still get: Apr 21 12:38:36 ifs sync_client[29518]: Reprocessing sync log file /var/lib/imap/sync/log-run Apr 21 12:43:27 ifs sync_client[29518]: IOERROR: zero length response to MAILBOXES (idle for too long) Apr 21 12:43:27 ifs sync_client[29518]: IOERROR: zero length response to RESTART (idle for too long) Apr 21 12:43:27 ifs sync_client[29518]: Error in do_sync(): bailing out! Bad protocol Apr 21 12:43:27 ifs sync_client[29518]: Processing sync log file /var/lib/imap/sync/log-run failed: Bad protocol 3. There is 27 GB of about 45 GB replicated and there is no further progress 4. How to find out why the replica doesn't respond? On 2020-04-21 11:18, Olaf Frączyk wrote: I also found out that when I see on master: Apr 21 11:12:38 ifs sync_client[27996]: IOERROR: zero length response to MAILBOXES (idle for too long) Apr 21 11:12:38 ifs sync_client[27996]: IOERROR: zero length response to RESTART (idle for too long) Apr 21 11:12:38 ifs sync_client[27996]: Error in do_sync(): bailing out! Bad protocol Apr 21 11:12:38 ifs sync_client[27996]: Processing sync log file /var/lib/imap/sync/log-run failed: Bad protocol I also get on the replica: Apr 21 11:12:38 skink1 imap[5775]: Connection reset by peer, closing connection But I also see, that before it happens, there is no activity both on the replica and on the master for some time. So maybe the imap server process is not recovering correctly in the longlock situation? On 2020-04-21 11:07, Olaf Frączyk wrote: Hi, When I run sync_client -r on the master I see the following on the replica: Apr 21 10:56:15 skink1 imap[5775]: mailbox: longlock navi.pl!user.olaf for 1.7 seconds Apr 21 10:56:20 skink1 imap[5775]: mailbox: longlock navi.pl!user.piotr for 2.0 seconds Apr 21 10:56:23 skink1 imap[5775]: mailbox: longlock navi.pl!user.olaf for 2.9 seconds Apr 21 10:56:26 skink1 imap[5775]: mailbox: longlock navi.pl!user.piotr for 3.0 seconds The mailboxes have several GB in Inbox folder and several GB in subfolders. The inbox folders have about 20,000 messages, the subfolders upto 15,000 Could it cause problems? Maybe I should move the sync_client from START section to SERVICES, it seems that it is not automatically restarted On 2020-04-21 08:47, Michael Menge wrote: Hi Olaf Quoting Olaf Frączyk : Hi, I upgraded to 3.0.13 but it didn't help. This time it copied about 18GB in the logs I still see: 1 - inefficient replication 2 - IOERROR: zero length response to MAILBOXES (idle for too long) IOERROR: zero length response to RESTART (idle for too long) Error in do_sync(): bailing out! Bad protocol But I have no idea what can I do next and why it fails Apr 21 02:24:46 ifs sync_client[12656]: IOERROR: zero length response to MAILBOXES (idle for too long) Apr 21 02:24:46 ifs sync_client[12656]: IOERROR: zero length response to RESTART (idle for too long) Apr 21 02:24:46 ifs sync_client[12656]: Error in do_sync(): bailing out! Bad protocol do you see any errors on the syncserver side. The error look like the sync_client is waiting for a reply of the server. M.Menge Tel.: (49) 7071/29-70316 Universität Tübingen Fax.: (49) 7071/29-5912 Zentrum für Datenverarbeitung mail: michael.me...@zdv.uni-tuebingen.de Wächterstraße 76 72074 Tübingen 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 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 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 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: Replication failed 3.0.5 -> 3.0.13, now 3.0.13->3.0.13
Thank you for the telemetry hint :) I don't use the syncserver - the replication is done via IMAP port on the replica side. I have no idea how to have strace spawned by cyrus master process. When I attach later to imapd using strace -p I'm afraid some info already will be lost. The syncserver is marked as deprecated in the docs, so I went with the more modern option. Maybe here is the problem ;) The funny thing is that from time to time the replication progresses a little. I don't like non-repetitive behavior ;) Thanks again for the hints. On 2020-04-21 14:13, Michael Menge wrote: Hi, Quoting Olaf Frączyk : The current situation is: 1. Replica: stopped and started the replica no activity on replica - iotop and top show nothing the only messages on replica is incoming connection from master 2. Master: when I run sync_client -r I still get: Apr 21 12:38:36 ifs sync_client[29518]: Reprocessing sync log file /var/lib/imap/sync/log-run Apr 21 12:43:27 ifs sync_client[29518]: IOERROR: zero length response to MAILBOXES (idle for too long) Apr 21 12:43:27 ifs sync_client[29518]: IOERROR: zero length response to RESTART (idle for too long) Apr 21 12:43:27 ifs sync_client[29518]: Error in do_sync(): bailing out! Bad protocol Apr 21 12:43:27 ifs sync_client[29518]: Processing sync log file /var/lib/imap/sync/log-run failed: Bad protocol 3. There is 27 GB of about 45 GB replicated and there is no further progress 4. How to find out why the replica doesn't respond? You can enable telemetry logging on the replica by creating a folder /var/lib/imap/log/ where is the value of the sync_authname. If you give cyrus write permissions for this folder it will create log-files for each process and what it received and send from/to the sync_client with timestamps. Also you can try to use strace on the syncserver process to figure out which files it is accessing On 2020-04-21 11:18, Olaf Frączyk wrote: I also found out that when I see on master: Apr 21 11:12:38 ifs sync_client[27996]: IOERROR: zero length response to MAILBOXES (idle for too long) Apr 21 11:12:38 ifs sync_client[27996]: IOERROR: zero length response to RESTART (idle for too long) Apr 21 11:12:38 ifs sync_client[27996]: Error in do_sync(): bailing out! Bad protocol Apr 21 11:12:38 ifs sync_client[27996]: Processing sync log file /var/lib/imap/sync/log-run failed: Bad protocol I also get on the replica: Apr 21 11:12:38 skink1 imap[5775]: Connection reset by peer, closing connection But I also see, that before it happens, there is no activity both on the replica and on the master for some time. So maybe the imap server process is not recovering correctly in the longlock situation? On 2020-04-21 11:07, Olaf Frączyk wrote: Hi, When I run sync_client -r on the master I see the following on the replica: Apr 21 10:56:15 skink1 imap[5775]: mailbox: longlock navi.pl!user.olaf for 1.7 seconds Apr 21 10:56:20 skink1 imap[5775]: mailbox: longlock navi.pl!user.piotr for 2.0 seconds Apr 21 10:56:23 skink1 imap[5775]: mailbox: longlock navi.pl!user.olaf for 2.9 seconds Apr 21 10:56:26 skink1 imap[5775]: mailbox: longlock navi.pl!user.piotr for 3.0 seconds The mailboxes have several GB in Inbox folder and several GB in subfolders. The inbox folders have about 20,000 messages, the subfolders upto 15,000 Could it cause problems? the longlock is normaly not the problem. While on process has the lock no other process can write to the mailbox, but on the replica there normaly is no other process that should access the mailbox Maybe I should move the sync_client from START section to SERVICES, it seems that it is not automatically restarted I havend tried starting sync_client in the service section. I start the sync_client via systemd. On 2020-04-21 08:47, Michael Menge wrote: Hi Olaf Quoting Olaf Frączyk : Hi, I upgraded to 3.0.13 but it didn't help. This time it copied about 18GB in the logs I still see: 1 - inefficient replication 2 - IOERROR: zero length response to MAILBOXES (idle for too long) IOERROR: zero length response to RESTART (idle for too long) Error in do_sync(): bailing out! Bad protocol But I have no idea what can I do next and why it fails Apr 21 02:24:46 ifs sync_client[12656]: IOERROR: zero length response to MAILBOXES (idle for too long) Apr 21 02:24:46 ifs sync_client[12656]: IOERROR: zero length response to RESTART (idle for too long) Apr 21 02:24:46 ifs sync_client[12656]: Error in do_sync(): bailing out! Bad protocol do you see any errors on the syncserver side. The error look like the sync_client is waiting for a reply of the server. M.Menge Tel.: (49) 7071/29-70316 Universität Tübingen Fax.: (49) 7071/29-5912 Zentrum für Datenverarbeitung mail: michael.me...@zdv.uni-tuebingen.d
Re: Replication failed 3.0.5 -> 3.0.13, now 3.0.13->3.0.13
t;, O_RDWR) = 8
fcntl(8, F_SETLKW, {l_type=F_WRLCK, l_whence=SEEK_SET, l_start=0,
l_len=0}) = 0
fcntl(8, F_SETLKW, {l_type=F_UNLCK, l_whence=SEEK_SET, l_start=0,
l_len=0}) = 0
read(8, "MAILBOX navi.pl!user.olaf\n", 4096) = 26
read(8, "", 4096) = 0
write(6, "\27\3\3\0B\372\222\265gb\346\246$\211
\367e\241\212\30\364\345[GJ\204\225\n\255?\356\343"..., 71) = 71
rt_sigprocmask(SIG_BLOCK, [INT QUIT ALRM TERM CHLD], [], 8) = 0
pselect6(7, [6], NULL, NULL, {0, 0}, {[], 8}) = 0 (Timeout)
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
sendto(7, "<179>Apr 21 14:56:46 sync_client"..., 103, MSG_NOSIGNAL,
NULL, 0) = 103
write(6,
"\27\3\3\0(\372\222\265gb\346\246%\216\222#\336\16t\320\236|bv\25\261)6/\242\217l"...,
45) = 45
sendto(7, "<179>Apr 21 14:56:46 sync_client"..., 101, MSG_NOSIGNAL,
NULL, 0) = 101
sendto(7, "<179>Apr 21 14:56:46 sync_client"..., 86, MSG_NOSIGNAL, NULL,
0) = 86
sendto(7, "<179>Apr 21 14:56:46 sync_client"..., 113, MSG_NOSIGNAL,
NULL, 0) = 113
close(8) = 0
write(6,
"\27\3\3\0\"\372\222\265gb\346\246&\261B\342|\260\231\217\307[\16\\\335\211\324w\345\2544\""...,
39) = 39
shutdown(6, SHUT_RD) = 0
close(6) = 0
close(5) = 0
munmap(0x7fc6ed5bb000, 16384) = 0
close(3) = 0
munmap(0x7fc6ed5d, 49152) = 0
close(4) = 0
exit_group(0) = ?
+++ exited with 0 +++
On 2020-04-21 15:00, Michael Menge wrote:
Quoting Olaf Frączyk :
Thank you for the telemetry hint :)
I don't use the syncserver - the replication is done via IMAP port on
the replica side. I have no idea how to have strace spawned by cyrus
master process. When I attach later to imapd using strace -p I'm
afraid some info already will be lost.
You can try "/usr/bin/strace /imapd
" as cmd
or you can use prefork=1 in the service to prefok one imap process and
connect
to this one before you start the sync_client.
The syncserver is marked as deprecated in the docs, so I went with
the more modern option. Maybe here is the problem ;)
i am using syncserver since cyrus-imapd 2.3. So I had no reason to
change it.
The funny thing is that from time to time the replication progresses
a little. I don't like non-repetitive behavior ;)
Thanks again for the hints.
On 2020-04-21 14:13, Michael Menge wrote:
Hi,
Quoting Olaf Frączyk :
The current situation is:
1. Replica:
stopped and started the replica
no activity on replica - iotop and top show nothing
the only messages on replica is incoming connection from master
2. Master:
when I run sync_client -r I still get:
Apr 21 12:38:36 ifs sync_client[29518]: Reprocessing sync log file
/var/lib/imap/sync/log-run
Apr 21 12:43:27 ifs sync_client[29518]: IOERROR: zero length
response to MAILBOXES (idle for too long)
Apr 21 12:43:27 ifs sync_client[29518]: IOERROR: zero length
response to RESTART (idle for too long)
Apr 21 12:43:27 ifs sync_client[29518]: Error in do_sync(): bailing
out! Bad protocol
Apr 21 12:43:27 ifs sync_client[29518]: Processing sync log file
/var/lib/imap/sync/log-run failed: Bad protocol
3. There is 27 GB of about 45 GB replicated and there is no further
progress
4. How to find out why the replica doesn't respond?
You can enable telemetry logging on the replica by creating a folder
/var/lib/imap/log/
where is the value of the sync_authname. If you give
cyrus write permissions for this folder
it will create log-files for each process and what it received and
send from/to the sync_client with timestamps.
Also you can try to use strace on the syncserver process to figure
out which files it is accessing
On 2020-04-21 11:18, Olaf Frączyk wrote:
I also found out that when I see on master:
Apr 21 11:12:38 ifs sync_client[27996]: IOERROR: zero length
response to MAILBOXES (idle for too long)
Apr 21 11:12:38 ifs sync_client[27996]: IOERROR: zero length
response to RESTART (idle for too long)
Apr 21 11:12:38 ifs sync_client[27996]: Error in do_sync():
bailing out! Bad protocol
Apr 21 11:12:38 ifs sync_client[27996]: Processing sync log file
/var/lib/imap/sync/log-run failed: Bad protocol
I also get on the replica:
Apr 21 11:12:38 skink1 imap[5775]: Connection reset by peer,
closing connection
But I also see, that before it happens, there is no activity both
on the replica and on the master for some time.
So maybe the imap server process is not recovering correctly in
the longlock situation?
On 2020-04-21 11:07, Olaf Frączyk wrote:
Hi,
When I run sync_client -r on the master I see the following on
the replica:
Apr 21 10:56:15 skink1 imap[5775]: mailbox: longlock
navi.pl!user.olaf for 1.7 seconds
Apr 21 10:56:20 skink1 imap[57
Re: Replication failed 3.0.5 -> 3.0.13, now 3.0.13->3.0.13
On 2020-04-21 16:00, Michael Menge wrote: Hi, Quoting Olaf Frączyk : I managed to get strace on both sides, however it doesn't make me wiser - there is nothing obvious for me. Additionally I see that replication works more or less for new messages, but older are not processed. I have several subfolders in my mailbox, some of them unreplicated. If I change anything in the subfolder now - the folder is replicated, but other subfolders remain not replicated - unless I change anything in them. you are trying to use rolling replication. For rolling replication cyrus logs which the location and type where changes ocure e.g "MAILBOX navi.pl!user.olaf" indicates that something has changed in the INBOX of the user o...@navi.pl. the rolling replication will keep the master and replica in sync, but it requires that there was an initial replication of all users. you can use sync_client with -A oder -u to do this synchronization (see the manpage for details) I think using rolling replication without the initial sync may be the cause of the errors. stop the "sync_client -r" and wait for the initial sync to finish. Yes, at the beginning I was also thinking if initial sync is necessary, but there was nothing in docs about it, something started replicating and I simply assumed it does initial resync. I'll try it this evening. :) Since you use replication - are sieve scripts replicated as well? There is -s option called sieve mode but it needs to specify which users' files are to replicate and there is written that it is mostly for debugging. M.Menge Tel.: (49) 7071/29-70316 Universität Tübingen Fax.: (49) 7071/29-5912 Zentrum für Datenverarbeitung mail: michael.me...@zdv.uni-tuebingen.de Wächterstraße 76 72074 Tübingen 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 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: Replication failed 3.0.5 -> 3.0.13, now 3.0.13->3.0.13
On 2020-04-21 20:40, Michael Menge wrote: Quoting Olaf Frączyk : Yes, at the beginning I was also thinking if initial sync is necessary, but there was nothing in docs about it, something started replicating and I simply assumed it does initial resync. I'll try it this evening. :) Since you use replication - are sieve scripts replicated as well? There is -s option called sieve mode but it needs to specify which users' files are to replicate and there is written that it is mostly for debugging. Yes, sieve scripts are replicated. The way the rolling replication works is, that every time something is changed on the master a "hint" is written in the sync log, "MAILBOX user.foo.bar" indicates that the mailbox bar of the user foo has changed and the sync_client will sync this (and only this folder) There are other "hints" e.g for changed subscription or changed sieve script. But if the sieve script is not changed sync_client in rolling replication will not try to sync it. Using the -A or -u Option will sync the all/some users, including all mailboxes, folder subscriptions and sieve scripts. The -s option is only needed if you change a compiled sieve script so that it is not logged in the replication log. I did replication with -A. It looks that everything works properly now. Sieve scripts were also transferred :) It is good to know, that if I change compiled script manually it needs additional attention. Thank you very much for help :) M.Menge Tel.: (49) 7071/29-70316 Universität Tübingen Fax.: (49) 7071/29-5912 Zentrum für Datenverarbeitung mail: michael.me...@zdv.uni-tuebingen.de Wächterstraße 76 72074 Tübingen 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 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: Replication failed 3.0.5 -> 3.0.13, now 3.0.13->3.0.13
Yes, Michael was right - it works properly now. (I hope ;). OK. I'll put it in the DAEMON section - this way I have only one point where all stuff related to imap is started. Thank you for explanation. Regards, Olaf On 2020-04-22 02:36, ellie timoney wrote: I think Michael's got this pretty much covered -- you need to disable the rolling replication for now, and then use sync_client -u (or if you're brave, sync_client -A) to get an initial sync of everything. These two options work entire-user-at-a-time, so they should detect and fix the problems introduced by the partial rolling sync. If you have mailboxes in a shared namespace (i.e. that are outside the user/ namespace), they won't be replicated by -u or -A. You'll need to initially replicate those individually with sync_client -m. Once you've got a complete initial sync done, you can use rolling replication to keep the replica up to date. You can put the rolling 'sync_client -r' in the DAEMON section, so that Cyrus will restart it if it exits. Or you could manage it from outside Cyrus, e.g. via systemd/initd if you prefer. You cannot put sync_client in the SERVICES section. The SERVICES section is for service processes (i.e. processes that listen on a socket and service client requests). sync_client is a client, not a service. Cheers, ellie On Wed, Apr 22, 2020, at 4:40 AM, Michael Menge wrote: Quoting Olaf Frączyk : Yes, at the beginning I was also thinking if initial sync is necessary, but there was nothing in docs about it, something started replicating and I simply assumed it does initial resync. I'll try it this evening. :) Since you use replication - are sieve scripts replicated as well? There is -s option called sieve mode but it needs to specify which users' files are to replicate and there is written that it is mostly for debugging. Yes, sieve scripts are replicated. The way the rolling replication works is, that every time something is changed on the master a "hint" is written in the sync log, "MAILBOX user.foo.bar" indicates that the mailbox bar of the user foo has changed and the sync_client will sync this (and only this folder) There are other "hints" e.g for changed subscription or changed sieve script. But if the sieve script is not changed sync_client in rolling replication will not try to sync it. Using the -A or -u Option will sync the all/some users, including all mailboxes, folder subscriptions and sieve scripts. The -s option is only needed if you change a compiled sieve script so that it is not logged in the replication log. M.MengeTel.: (49) 7071/29-70316 Universität Tübingen Fax.: (49) 7071/29-5912 Zentrum für Datenverarbeitung mail: michael.me...@zdv.uni-tuebingen.de Wächterstraße 76 72074 Tübingen 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 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 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: Replication failed 3.0.5 -> 3.0.13
On 2020-04-22 09:16, Andrzej Kwiatkowski wrote: W dniu 20.04.2020 o 16:11, Olaf Frączyk pisze: Hi, I'm running 3.0.5. I want to migrate to a new machine. I set up cyrus-imapd 3.0.13. The replication started but it didn't transfer all mails. The store isn't big 44GB, transferred was about 24 GB. In the logs I see: Olaf, Do you install 3.0.13 on vm or bare-metal ? Regards AK I have it installed in VM - CentOS 7, now 8. This setup worked OK for many years. But I have only a few users, just with big mailboxes. On SAS drives it works fine. The only longlock I saw was during the replication - I suppose transferring 20.000 big messages at once per mailbox could cause it. But in normal usage I don't see it. The cause of my problem was my ignorance regarding how rolling replication works in cyrus. It works OK now :) Regards, Olaf 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
sync_log_chain - is it always needed?
Hello, I was wondering why do we need to use this option on middle servers in replication chain? I don't use sync_server. The replication is done using IMAP protocol. Is in this case this setting also necessary? Shouldn't the middle server catch all changes that are done via IMAP protocol and forward them to the next server in the replication chain? BTW. Does anyone has some description how sieve scripts replication is done via IMAP protocol? Best regards, OIaf 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: sync_log_chain - is it always needed?
On 2020-04-29 03:39, ellie timoney wrote: On Wed, Apr 29, 2020, at 1:12 AM, Olaf Frączyk wrote: I was wondering why do we need to use this option on middle servers in replication chain? Hope this helps, Yes it helped. Thank you. As the replication uses its own protocol even over IMAP connection it makes sense. However why the sync_log_chain could be not always active? As the server catches all changes from LMTP, IMAP, POP anyway, why to use a special option for the synchronization protocol? Why to treat replication changes differently from LMTP/IMAP? If we want replication - we want to catch all changes - regardless of the source, if we don't do replication - we don't need to catch any changes. ellie 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 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: Replication failed 3.0.5 -> 3.0.13
On 2020-04-29 16:47, Andrzej Kwiatkowski wrote: Ok. I was asking because of problem with low entropy on VM-s causing performance issues with big installations. I didn't have this issue, however as I said, my installation is really small. If I needed more entropy I would think of using a hardware entropy generator. Eg. on a PCI-e card. They aren't super cheap but also not too expensive. I think someone with good cryptography knowledge could help you with this topic. I suppose the storage I/O can be a bigger issue here. I've also noticed that replication documentation is a bit tricky, and not every procedure/case is well documented. Yes, me too ;) But if you hit a bigger problem, you have this list :) I tried on a copy without active users to be safe. Regards AK 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: sync_log_chain - is it always needed?
On 2020-05-01 01:26, ellie timoney wrote: The rolling sync_client takes care of cleaning up each sync_log file as it finishes replicating it downstream. Now consider the case where your replica is an end point, not a link in a chain: it does not have a rolling sync_client forwarding replications on, so if it automatically logged incoming replications to the sync_log, the sync_log would simply grow forever and fill the disk. You would need to set up a special job to delete it Better to simply not write it in the first place! Thus, the default is to sync_log_chain: off, and if you need the special-case chaining behaviour, you turn it on. Just to clarify here - are not IMAP/POP/LMTP actions logged anyway - using sync_log? Won't they grow forever, too? What is a scenario where sync_log and sync_log_chain is used independently? What is the purpose to have sync_log and sync_log_chain as separate options - couldn't we just use sync_log? Are both types of entries - from sync_log and sync_log_chain used only by rolling replication? Or are they used by sync_client -A too? Sorry for the silly questions, the replication is quite scantly documented. Thank you for all the explanations so far, regards, Olaf Cheers, ellie 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 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
sync_client -r stops working after several minutes
Hi,
cyrus-imapd 3.0.13, CentOS 8
replication over IMAP, no sync_server
I try to find out why rolling replication is failing in my case. They
sync_client -A works fine.
I have enabled logging for cyrus_admin in /var/lib/imap/log/cyrus_admin
On the replica side /var/lib/imap/log/cyrus_admin:
>1588340782>S8 OK success
<15883407821588340782>S9 OK Restarting
<1588341098>1588341098>* MAILBOX %(UNIQUEID 7f969c134bd149a0 MBOXNAME
navi.pl!user.info.Junk SYNC_CRC 1665461165 SYNC_CRC_ANNOT 0 LAST_UID
67313 HIGHESTMODSEQ 158640 RECENTUID 67252 REC
ENTTIME 1588266136 LAST_APPENDDATE 1588339875 POP3_LAST_LOGIN 0
POP3_SHOW_AFTER 0 UIDVALIDITY 1272007072 PARTITION default ACL
"i...@navi.pl lrswipkxtecda " OPTIONS P
ANNOTATIONS (%(ENTRY /specialuse USERID i...@navi.pl VALUE {5}
\Junk)))
S10 OK success
<15883410981588341098>S11 OK Restarting
<1588341098stat("/var/local/imapd_sync_stop", 0x7ffe1a0106b0) = -1 ENOENT (No such
file or directory)
stat("/var/lib/imap/sync/log-run", 0x7ffe1a0105c0) = -1 ENOENT (No such
file or directory)
stat("/var/lib/imap/sync/log", 0x7ffe1a0105c0) = -1 ENOENT (No such file
or directory)
nanosleep({tv_sec=1, tv_nsec=0}, 0x7ffe1a010630) = 0
stat("/var/local/imapd_sync_stop", 0x7ffe1a0106b0) = -1 ENOENT (No such
file or directory)
stat("/var/lib/imap/sync/log-run", 0x7ffe1a0105c0) = -1 ENOENT (No such
file or directory)
stat("/var/lib/imap/sync/log", 0x7ffe1a0105c0) = -1 ENOENT (No such file
or directory)
nanosleep({tv_sec=1, tv_nsec=0}, 0x7ffe1a010630) = 0
stat("/var/local/imapd_sync_stop", 0x7ffe1a0106b0) = -1 ENOENT (No such
file or directory)
stat("/var/lib/imap/sync/log-run", 0x7ffe1a0105c0) = -1 ENOENT (No such
file or directory)
stat("/var/lib/imap/sync/log", 0x7ffe1a0105c0) = -1 ENOENT (No such file
or directory)
nanosleep({tv_sec=1, tv_nsec=0}, 0x7ffe1a010630) = 0
stat("/var/local/imapd_sync_stop", 0x7ffe1a0106b0) = -1 ENOENT (No such
file or directory)
stat("/var/lib/imap/sync/log-run", 0x7ffe1a0105c0) = -1 ENOENT (No such
file or directory)
stat("/var/lib/imap/sync/log", {st_mode=S_IFREG|0600, st_size=61, ...}) = 0
rename("/var/lib/imap/sync/log", "/var/lib/imap/sync/log-run") = 0
openat(AT_FDCWD, "/var/lib/imap/sync/log-run", O_RDWR) = 11
fcntl(11, F_SETLKW, {l_type=F_WRLCK, l_whence=SEEK_SET, l_start=0,
l_len=0}) = 0
fcntl(11, F_SETLKW, {l_type=F_UNLCK, l_whence=SEEK_SET, l_start=0,
l_len=0}) = 0
read(11, "APPEND navi.pl!user.info.Junk\nMA"..., 4096) = 61
read(11, "", 4096) = 0
write(8,
"\27\3\3\0A\t*\315\322y\376XR\"\203\234\335\1\346-\v\21\231\36\30\232Q\233\272\264\370\275"...,
70) = 70
rt_sigprocmask(SIG_BLOCK, [INT QUIT ALRM TERM CHLD], [], 8) = 0
pselect6(9, [8], NULL, NULL, {tv_sec=0, tv_nsec=0}, {[], 8}) = 0 (Timeout)
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
getpid() = 32350
sendto(9, "<179>May 1 15:51:38 sync_client"..., 103, MSG_NOSIGNAL,
NULL, 0) = 103
write(8,
"\27\3\3\0\"I\26*2S\3548>\n\375\338\30\333\334\334%\3417\350eR\227\35\305\201W"...,
39) = 39
getpid() = 32350
sendto(9, "<179>May 1 15:51:38 sync_client"..., 101, MSG_NOSIGNAL,
NULL, 0) = 101
getpid() = 32350
sendto(9, "<179>May 1 15:51:38 sync_client"..., 86, MSG_NOSIGNAL, NULL,
0) = 86
getpid() = 32350
sendto(9, "<179>May 1 15:51:38 sync_client"..., 113, MSG_NOSIGNAL,
NULL, 0) = 113
close(11) = 0
write(8,
"\27\3\3\0\33\375R\225I\325\271\215~\24\311\224\272\235g\326\206$?\226\203\261\23\247\24\206\270n",
32) = 32
shutdown(8, SHUT_RD) = 0
close(8) = 0
close(7) = 0
munmap(0x7fe2e72dc000, 16384) = 0
close(6) = 0
munmap(0x7fe2e72be000, 40960) = 0
close(4) = 0
exit_group(0) = ?
+++ exited with 0 +++
From /var/log/messages:
May 1 15:37:43 skink1 sync_client[32113]: Processing sync log file
/var/lib/imap/sync/log-run failed: Bad protocol
May 1 15:46:21 skink1 sync_client[32350]: auditlog: proxy
sessionid=
remote=
May 1 15:46:21 skink1 sync_client[32350]: Reprocessing sync log file
/var/lib/imap/sync/log-run
May 1 15:51:38 skink1 sync_client[32350]: IOERROR: zero length response
to MAILBOXES (idle for too long)
May 1 15:51:38 skink1 sync_client[32350]: IOERROR: zero length response
to RESTART (idle for too long)
May 1 15:51:38 skink1 sync_client[32350]: Error in do_sync(): bailing
out! Bad protocol
May 1 15:51:38 skink1 sync_client[32350]: Processing sync log file
/var/lib/imap/sync/log-run failed: Bad protocol
What can I do more to find what causes this problem?
Best regards,
Olaf
--
NAVI Sp. z o.o.
Promienista 5/1
60-288 Poznań
mobile: +48609769035
phone: +48616622881
fax: +48616622882
http://www.navi.pl
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://
