Backend reboot replication lost
Dear cyrus friends, Once more my backend server was rebooted. I did not find any messages in my logs nor did I receive any screen messages, that the replication was stopped. I wonder what will happen in a production environment, when the server reboots without my notice. Replication will fail and I will not be able to guarantee full recovery. To my opinion this is unacceptable. Best would be to incorporate a message system about failure in the sync_client code. I found some entries in the logs of the backend server about access of the replication user: every 10 minutes the user logs on to the backend server. Most probably to replicate the mails. I might use this behavior as a sign of a working replication mechanism. It is only indirect, but it tells me that there is at least some activity from the client to the backend. I wonder why the user is logging on every 10 minutes. Does it mean that the mails, received for the last 9 minutes or so, are not replicated? I'm not very experience in coding, but I will try to dig into the sync_client code and see how things are organised. I restarted the replication by executing ``sync_client -r'' on the client. I do not even know if this is the right step to take to reactivate replication. Can someone confirm? I can see in the logs of the backend, that the replication user logs on every 10 minutes again. I take that as a positive sign, that ``sync_client -r'' restarts the replication, but I have no clue about inconsistencies or other possible checks. -- Met vriendelijke groeten, With kind regards, Mit freundlichen Gruessen, De jrus wah, Willy * W.K. Offermans Home: +31 45 544 49 44 Mobile: +31 681 15 87 68 e-mail: wi...@offermans.rompen.nl 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: Outlook 2013
On Thu, 2014-02-27 at 21:58 +0100, Paul van der Vlis wrote: I would like to tell that I got some private mails telling that Outlook 2013 does not work well with imap. I have several users using Outlook with Cyrus IMAPd; it works without issue. At least from 2003 and later. One tip is to disable Exchange extensions, but other than that no hacking is required. -- Adam Tauno Williams mailto:awill...@whitemice.org GPG D95ED383 Systems Administrator, Python Developer, LPI / NCLA 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: Backend reboot replication lost
Hi
Quoting Willy Offermans wi...@offermans.rompen.nl:
Dear cyrus friends,
Once more my backend server was rebooted. I did not find any messages in my
logs nor did I receive any screen messages, that the replication was
stopped. I wonder what will happen in a production environment, when the
server reboots without my notice. Replication will fail and I will not be
able to guarantee full recovery. To my opinion this is unacceptable.
Best would be to incorporate a message system about failure in the
sync_client code.
I found some entries in the logs of the backend server about access of the
replication user: every 10 minutes the user logs on to the backend server.
Most probably to replicate the mails. I might use this behavior as a sign
of a working replication mechanism. It is only indirect, but it tells me
that there is at least some activity from the client to the backend. I
wonder why the user is logging on every 10 minutes. Does it mean that the
mails, received for the last 9 minutes or so, are not replicated?
I'm not very experience in coding, but I will try to dig into the
sync_client code and see how things are organised.
I restarted the replication by executing ``sync_client -r'' on the client.
I do not even know if this is the right step to take to reactivate
replication. Can someone confirm? I can see in the logs of the backend,
that the replication user logs on every 10 minutes again. I take that as a
positive sign, that ``sync_client -r'' restarts the replication, but I have
no clue about inconsistencies or other possible checks.
If you have configured rolling replication, every change will be logged
to the {configdirectory}/sync/log file. The 'sync_client -r' will check
for this file, move it to {configdirectory}/sync/log-pid, process the file
and checks again for a new {configdirectory}/sync/log
If 'sync_client -r' is not running has crashed {configdirectory}/sync/log
will grow. So by checking the filesize of the log you know if you replic is
up to date.
If sync_client stops, and there is a log-pid file present,
you run sync_client -r -f {configdirectory}/sync/log-pid
and check that the exit code. If it is 0 you can remove the
log-pid file and restart 'sync_cliet -r', if not check the logs
for errors.
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
smime.p7s
Description: S/MIME Signatur
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: Sieve service terminated abnormally
On Thu, 2014-02-27 at 15:34 -0300, Fabio S. Schmidt wrote: I'm running Cyrus 2.4.14 with Aggregator and this messages appears several times on my frontend logs: service sieve pid 10238 in BUSY state: terminated abnormally I have not seen that message. Do you end up with a core file? What does this mean? Do I have to increase the maxchild for the sieve service or my clients are doing something wrong? Are you clients unable to connect after this message? -- Adam Tauno Williams mailto:awill...@whitemice.org GPG D95ED383 Systems Administrator, Python Developer, LPI / NCLA 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: Ubuntu 13.10 | Cyrus 2.4 IMAPd | Specs Folders
Hi Andrew, thanks for sharing your experience here ! We use Cyrus 2.4.14 and are planning to update to 2.4.17 soon, and autocreate would be really useful for us, does anyone know if it works with Aggregator? Some time ago I have downloaded the autocreate patch for cyrus 2.4.12 and it worked on 2.4.14 without aggregator : https://blog.vx.sk/archives/13-Autocreate-and-autosieve-patches-for-Cyrus-IMAP-Server-24.html Does anyone known if the autocreate will be avaliable on a next release or in the 2.5 version? Another resource that would be useful is the possibilty to define the sieve reject automatic message, which currently is fixed on the code. For instance, my users were thinking that these messages were Spam because the were in English and I needed to translate to Brazilian Portuguese. On 24 February 2014 09:59, andrew_...@hotmail.com wrote: I solve it. Next should changed in imapd.conf: altnamespace: yes autocreatequota: -1 #it can be a positive value. allowplaintext: yes sasl_mech_list: PLAIN sasl_pwcheck_method: saslauthd #end of file: xlist-drafts: Drafts xlist-archive: Archive xlist-sent: Sent Items xlist-trash: Deleted Items xlist-junk: Junk E-mail xlist-spam: Junk E-mail Looks like it is working with Outlook 2013, but i didnt test it deaply. It is working good by Windows live mail 2012 and Thunderbird . -Oorspronkelijk bericht- From: Sebastian Hagedorn Sent: Saturday, February 22, 2014 10:53 AM To: Andrey Cc: info-cyrus@lists.andrew.cmu.edu Subject: Re: Ubuntu 13.10 | Cyrus 2.4 IMAPd | Specs Folders However, I came across a problem. When I log in from Windows Live Mail Cyrus automatically create only Inbox folder and no xlist-* rfc 6154 special maps (SENT DRAFTS TRASH etc.). In older versions there was an autocreate patch: http://code.uoa.gr/p/cyrus/autocreate/ There is no patch for 2.4.+. Does someone know how to solve this problem? Simon Matter's RPMs still have an autocreate patch: http://www.invoca.ch/pub/packages/cyrus-imapd/ FWIW, we decided not to support Outlook 2013. It's just horribly broken. -- Sebastian Hagedorn - Weyertal 121, Zimmer 2.02 Regionales Rechenzentrum (RRZK) Universität zu Köln / Cologne University - Tel. +49-221-470-89578 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 -- My best regards, Fabio Soares Schmidt Linux Professional Institute - LPIC-3 Microsoft Certified Technology Specialist: Active Directory 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: Sieve service terminated abnormally
Hi Adam ! Thanks for the answer. The users are not complaining about the Sieve service and the clients are able to connect after these messages. Sorry, I didn't understand what you said about a core file. On 28 February 2014 18:40, Adam Tauno Williams awill...@whitemice.orgwrote: On Thu, 2014-02-27 at 15:34 -0300, Fabio S. Schmidt wrote: I'm running Cyrus 2.4.14 with Aggregator and this messages appears several times on my frontend logs: service sieve pid 10238 in BUSY state: terminated abnormally I have not seen that message. Do you end up with a core file? What does this mean? Do I have to increase the maxchild for the sieve service or my clients are doing something wrong? Are you clients unable to connect after this message? -- Adam Tauno Williams mailto:awill...@whitemice.org GPG D95ED383 Systems Administrator, Python Developer, LPI / NCLA 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 -- My best regards, Fabio Soares Schmidt Linux Professional Institute - LPIC-3 Microsoft Certified Technology Specialist: Active Directory 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
