<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://blog.gmane.org/gmane.mail.imap.cyrus">
    <title>gmane.mail.imap.cyrus</title>
    <link>http://blog.gmane.org/gmane.mail.imap.cyrus</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.mail.imap.cyrus/37421"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.mail.imap.cyrus/37420"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.mail.imap.cyrus/37419"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.mail.imap.cyrus/37418"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.mail.imap.cyrus/37417"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.mail.imap.cyrus/37416"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.mail.imap.cyrus/37415"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.mail.imap.cyrus/37414"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.mail.imap.cyrus/37413"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.mail.imap.cyrus/37412"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.mail.imap.cyrus/37411"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.mail.imap.cyrus/37410"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.mail.imap.cyrus/37409"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.mail.imap.cyrus/37408"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.mail.imap.cyrus/37407"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.mail.imap.cyrus/37406"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.mail.imap.cyrus/37405"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.mail.imap.cyrus/37404"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.mail.imap.cyrus/37403"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.mail.imap.cyrus/37402"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://permalink.gmane.org/gmane.mail.imap.cyrus/37421">
    <title>Re: sync_client failing with "Fatal error: failed to finish readingfile!"</title>
    <link>http://permalink.gmane.org/gmane.mail.imap.cyrus/37421</link>
    <description>&lt;pre&gt;
The directories and files are all user=cyrus, group=mail and all perms
seem to be correct: 700 for directories and 600 for files.  Given that
we only see this on the middle system in a replication chain, we suspect
that perhaps the sync_server is still writing the file while the
sync_client starts to slurp it in.  Any chance this is the case?

What sucks for us about this is that sync_client dies, so the host at
the end of the chain falls out of sync, requiring manual intervention.

Cheers,
    -nic

&lt;/pre&gt;</description>
    <dc:creator>Nic Bernstein</dc:creator>
    <dc:date>2013-06-17T15:25:49</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.mail.imap.cyrus/37420">
    <title>login in sieveshell and cyradmin not possible fter setting saservername in imapd.conf</title>
    <link>http://permalink.gmane.org/gmane.mail.imap.cyrus/37420</link>
    <description>&lt;pre&gt;Hello list,

I have a Cyrus 2.2 running on a Debian Squeeeze box.
After setting an explicit servername in imapd.conf which is _not_ the same as 
that returned by gethostname(2).
e.g. 
servername: imap.local.domain
gethostname(2) returns machine1.local.domain

Mail-clients like KMail still can access the mailboxes.
However, cyradmin and sieveshell give me an authentication error.

Authentication runs with sasl and DIGEST-MD5

Thanks in advance


Harry

----
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

&lt;/pre&gt;</description>
    <dc:creator>Dr. Harry Knitter</dc:creator>
    <dc:date>2013-06-17T08:54:11</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.mail.imap.cyrus/37419">
    <title>Re: sync_client failing with "Fatal error: failed to finish readingfile!"</title>
    <link>http://permalink.gmane.org/gmane.mail.imap.cyrus/37419</link>
    <description>&lt;pre&gt;
(I'm just keeping the important lines here)





No, if size &amp;lt; 0 then we've read PAST the end of the file - which is also
totally bogus.  I can see a case for while (size &amp;gt; 0) on the loop though,
for this exact case, so we drop out earlier than EOF.

There are only two ways to exit that loop: either size gets down to zero,
or fread returns a non-positive value.  From the man page:

RETURN VALUE
        On success, fread() and fwrite() return the number of
        items read or written.
        This number equals the number of bytes transferred only
        when size is 1.  If an error occurs, or the end of the
        file is reached, the return value is a short item count
        (or zero).

        fread() does not distinguish between end-of-file and
        error, and callers must use feof(3) and ferror(3) to
        determine which occurred.

So we could certainly make the code better about reporting the
cause of the error.  I suspect 99% probability file permissions
problems (your 'cyrus' user can't read it, but can stat it) and
1% probability a corrupt filesystem with that file contents
being unreadable.  It's probably the very first fread which is
failing.

Regards,

Bron.

&lt;/pre&gt;</description>
    <dc:creator>Bron Gondwana</dc:creator>
    <dc:date>2013-06-17T06:00:50</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.mail.imap.cyrus/37418">
    <title>Sieve vacation in virtdomains / ldap</title>
    <link>http://permalink.gmane.org/gmane.mail.imap.cyrus/37418</link>
    <description>&lt;pre&gt;Hi,
we've been using cyrus for years in pam auth mode, with vacation scripts working correctly.
We recently switched to virtdomains: userid using ldap authentication.
Since this switch, vacation scripts are never considered, while filters parts of the script work fine.
Sieve scripts are usually like this:
#
# Generated by Sonicle WebTop Services [http://www.sonicle.com]
#
require ["fileinto","vacation","reject"];
if anyof (header :contains "subject" "***SPAM***") {
fileinto "Spam";
}
else {
keep;
}
vacation :days 1 :addresses ["realmail&amp;lt; at &amp;gt;realdomain.com"] text:
Test risposta automatica.
.
;
Is there anything to consider in virtomains mode??
Thanks for any help
Gabriele.
----
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&lt;/pre&gt;</description>
    <dc:creator>Gabriele Bulfon</dc:creator>
    <dc:date>2013-06-15T10:09:42</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.mail.imap.cyrus/37417">
    <title>Re: sync_client failing with "Fatal error: failed to finish readingfile!"</title>
    <link>http://permalink.gmane.org/gmane.mail.imap.cyrus/37417</link>
    <description>&lt;pre&gt;List,
Checking the source for dlist.c, here is the context for this error
[printfile()]:

    static void printfile(struct protstream *out, const struct dlist *dl)
    {
        char buf[4096];
        struct stat sbuf;
        FILE *f;
        unsigned long size;

        f = fopen(dl-&amp;gt;sval, "r");
        if (!f) {
    syslog(LOG_ERR, "IOERROR: Failed to read file %s", dl-&amp;gt;sval);
    prot_printf(out, "NIL");
    return;
        }
        if (fstat(fileno(f), &amp;amp;sbuf) == -1) {
    syslog(LOG_ERR, "IOERROR: Failed to stat file %s", dl-&amp;gt;sval);
    prot_printf(out, "NIL");
    fclose(f);
    return;
        }
        size = sbuf.st_size;
        if (size != dl-&amp;gt;nval) {
    syslog(LOG_ERR, "IOERROR: Size mismatch %s (%lu != " MODSEQ_FMT ")",
           dl-&amp;gt;sval, size, dl-&amp;gt;nval);
    prot_printf(out, "NIL");
    fclose(f);
    return;
        }

        prot_printf(out, "%%{");
        prot_printastring(out, dl-&amp;gt;part);
        prot_printf(out, " ");
        prot_printastring(out, message_guid_encode(&amp;amp;dl-&amp;gt;gval));
        prot_printf(out, " %lu}\r\n", size);

        while (size) {
    int n = fread(buf, 1, (size &amp;gt; 4096 ? 4096 : size), f);
    if (n &amp;lt;= 0) break;
    prot_write(out, buf, n);
    size -= n;
        }
        fclose(f);

        if (size) fatal("failed to finish reading file!", EC_IOERR);
    }

The only way we can see this happening is if size &amp;lt;0; in other words,
something has written more into the file since we opened it.  Is that a
correct interpretation?  If so, the error message doesn't really jive
with the error condition.  Shouldn't the test be:
    if (size &amp;gt; 0) fatal...
instead?  If size &amp;lt; 0, then manifestly we have finished reading the file.

Cheers,
    -nic
On 06/11/2013 01:34 PM, Nic Bernstein wrote:

&lt;/pre&gt;</description>
    <dc:creator>Nic Bernstein</dc:creator>
    <dc:date>2013-06-11T20:07:24</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.mail.imap.cyrus/37416">
    <title>sync_client failing with "Fatal error: failed to finish reading file!"</title>
    <link>http://permalink.gmane.org/gmane.mail.imap.cyrus/37416</link>
    <description>&lt;pre&gt;Friends,
We've been running a pair of replicas with Ken's
cyrus-imapd-2.4.17-caldav-beta (4 and 5) recently, in preparation for a
migration away from a single 2.4.11 server.  The configuration is the
2.4.11 box is the master, it replicates to the first 2.4.17 box, which
is also running a sync_client instance to replicate to the second 2.4.17
box.  The intent is that once the client is ready, we abandon the 2.4.11
box and the first 2.4.17 instance becomes the master and the second the
replica.

This has all been running pretty well, but lately the sync_client on the
middle box has failed a few times.  Each time, I see this in the logs
(The 2.4.11 master server has nothing in this time interval):

    # The 2.4.17 replica -- in the middle:
    Jun 11 13:36:09 mailbox cyrus/sync_client[29338]: sync_client RESTART succeeded
    Jun 11 13:36:10 mailbox cyrus/sync_client[29338]: COMPRESS received NO response: Compression already active: DEFLATE
    Jun 11 13:36:10 mailbox cyrus/sync_client[29338]: Failed to enable compression, continuing uncompressed
    Jun 11 13:36:52 mailbox cyrus/sync_client[29338]: Fatal error: failed to finish reading file!

    # The 2.4.17 replica, end of the chain:
    Jun 11 13:36:16 ia24 cyrus/syncserver[21234]: accepted connection
    Jun 11 13:36:16 ia24 cyrus/syncserver[21234]: cmdloop(): startup
    Jun 11 13:36:16 ia24 cyrus/syncserver[21234]: login: mailbox.wi.occinc.com [192.168.190.24] mailproxy PLAIN User logged in
    Jun 11 13:36:59 ia24 cyrus/syncserver[21234]: IOERROR: reading message: unexpected end of file

Can anyone tell me what this is indicative of?  A search of the web
doesn't turn up any hits for "Fatal error: failed to finish reading file!"

Thanks in advance!
    -nic

&lt;/pre&gt;</description>
    <dc:creator>Nic Bernstein</dc:creator>
    <dc:date>2013-06-11T18:34:01</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.mail.imap.cyrus/37415">
    <title>Re: cyrus-imapd-2.4.17-caldav-beta5 released</title>
    <link>http://permalink.gmane.org/gmane.mail.imap.cyrus/37415</link>
    <description>&lt;pre&gt;Hi Ondrej,


I have not done any testing with unixhierarchysep or virtdomains. From 
the error messages below, it looks like the mailbox name translation is 
not being done properly, or not being done at all.

I will look into this today.


On 06/11/2013 09:54 AM, Ondřej Surý wrote:


&lt;/pre&gt;</description>
    <dc:creator>Ken Murchison</dc:creator>
    <dc:date>2013-06-11T14:01:40</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.mail.imap.cyrus/37414">
    <title>Re: Trouble with sieve</title>
    <link>http://permalink.gmane.org/gmane.mail.imap.cyrus/37414</link>
    <description>&lt;pre&gt;
On 6/5/13 8:11 AM, Dan White wrote:

It uploaded just fine, and it was activated just fine. It appears it was 
successfully compiled to bytecode (there are binary files aside the 
script on the server), but I can't be totally certain - how do I tell?

Jason
----
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

&lt;/pre&gt;</description>
    <dc:creator>Jason Bailey</dc:creator>
    <dc:date>2013-06-05T19:49:57</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.mail.imap.cyrus/37413">
    <title>Re: Trouble with sieve</title>
    <link>http://permalink.gmane.org/gmane.mail.imap.cyrus/37413</link>
    <description>&lt;pre&gt;
Did you activate the uploaded script? Was the script successfully compiled
to bytecode?

&lt;/pre&gt;</description>
    <dc:creator>Dan White</dc:creator>
    <dc:date>2013-06-05T14:11:11</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.mail.imap.cyrus/37412">
    <title>Trouble with sieve</title>
    <link>http://permalink.gmane.org/gmane.mail.imap.cyrus/37412</link>
    <description>&lt;pre&gt;All,

I have a CentOS 6 mail system running Cyrus version 2.3.16, which is 
configured to use virtual domains. Sieve is enabled, and indeed runs for 
some mailboxes, but not for others. I'm struggling to find a solution.

Case in point. I have a script that is supposed to file incoming 
messages into specific sub-folders. The problem is, it doesn't do 
anything (script doesn't seem to execute). Messages simply arrive in the 
root of the inbox. I'm puzzled because I have used this very same script 
for years.

Message sources show that the X-Sieve header is set and is reporting CMU 
Sieve 2.3. The server also shows sieve listening on port 4190. Scripts 
uploaded with sieveshell are copied and installed without error.

I looked at my mail log, but it isn't telling me much. The only Cyrus 
related error I can find is one about "duplicate_mark". There isn't much 
there about Sieve besides logins.

I ran sivtest and all seems good there. I'm not sure what to look for.

Any ideas? Help is appreciated.

&lt;/pre&gt;</description>
    <dc:creator>Jason Bailey</dc:creator>
    <dc:date>2013-06-04T23:11:49</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.mail.imap.cyrus/37411">
    <title>Re: namesppace trouble</title>
    <link>http://permalink.gmane.org/gmane.mail.imap.cyrus/37411</link>
    <description>&lt;pre&gt;It's not a FreeBSD specific matter.

See man imapd.conf and you can find following
  hashimapspool: 0
so it's the default behavior.

On Mon, 03 Jun 2013 05:05:30 +0900, Riccardo Veraldi &amp;lt;Riccardo.Veraldi&amp;lt; at &amp;gt;cnaf.infn.it&amp;gt; wrote:



&lt;/pre&gt;</description>
    <dc:creator>OBATA Akio</dc:creator>
    <dc:date>2013-06-03T01:29:06</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.mail.imap.cyrus/37410">
    <title>Re: namesppace trouble</title>
    <link>http://permalink.gmane.org/gmane.mail.imap.cyrus/37410</link>
    <description>&lt;pre&gt;

yes u are right

but on FreeBSD 9.1 with cyrus version from ports collection happen this...

/var/spool/imap/user/username

so i asked if there is a way to change this behaviour

thank you


On 6/2/13 9:49 PM, Bron Gondwana wrote:

----
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

&lt;/pre&gt;</description>
    <dc:creator>Riccardo Veraldi</dc:creator>
    <dc:date>2013-06-02T20:05:30</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.mail.imap.cyrus/37409">
    <title>Re: namesppace trouble</title>
    <link>http://permalink.gmane.org/gmane.mail.imap.cyrus/37409</link>
    <description>&lt;pre&gt;
Note: accuracy is important.  That doesn't happen.  You can get this:

/var/spool/imap/u/user/username
/var/spool/imap/f/user/foo

But the hashing is never the other way around.  For domains it is

/var/spool/imap/domain/d/domain.com/f/user/foo/

(no, it's not entirely sane - but that's how it is)

Bron.

&lt;/pre&gt;</description>
    <dc:creator>Bron Gondwana</dc:creator>
    <dc:date>2013-06-02T19:49:43</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.mail.imap.cyrus/37408">
    <title>6/2/2013 1:56:17 PM</title>
    <link>http://permalink.gmane.org/gmane.mail.imap.cyrus/37408</link>
    <description>&lt;pre&gt;http://mirfilologa.ru/jran/cljgbqcgijeqskkmhrqtl.yey
----
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

&lt;/pre&gt;</description>
    <dc:creator>Davide Pasquale</dc:creator>
    <dc:date>2013-06-02T12:56:18</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.mail.imap.cyrus/37407">
    <title>Re: namesppace trouble</title>
    <link>http://permalink.gmane.org/gmane.mail.imap.cyrus/37407</link>
    <description>&lt;pre&gt;it is the default should be false

#hashimapspool: false


but anyway  all the mailboxes are created with username into

/var/spool/imap/user/username

while I wanted them to be


/var/spool/imap/user/u/username

I can't figure out while this cyrus-imapd from FreeBSD ports is not like that...

the  cyrus-imap for linux rpm downloaded from invoca.ch has the "standard" behaviour

/var/spool/imap/user/u/username


thank you



On 6/1/13 2:09 PM, Simon Matter wrote:

----
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

&lt;/pre&gt;</description>
    <dc:creator>fddi</dc:creator>
    <dc:date>2013-06-01T12:22:44</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.mail.imap.cyrus/37406">
    <title>Re: namesppace trouble</title>
    <link>http://permalink.gmane.org/gmane.mail.imap.cyrus/37406</link>
    <description>&lt;pre&gt;
What's you 'hashimapspool' setting? Is it 0|false?

Regards
Simon



----
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

&lt;/pre&gt;</description>
    <dc:creator>Simon Matter</dc:creator>
    <dc:date>2013-06-01T12:09:59</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.mail.imap.cyrus/37405">
    <title>namesppace trouble</title>
    <link>http://permalink.gmane.org/gmane.mail.imap.cyrus/37405</link>
    <description>&lt;pre&gt;Hello,
the cyrus namespace base is located in my default installation in

/var/spool/imap/user/

I expected afterrunning the mkimap script to find the alphabetical 
letters of the usernames in that directory:

a
b
c
d
e

and so on

and have every user mailbox created in the dorresponding alphabetical 
subdirectory

for example user foo would be in

/var/spool/imap/user/f/foo

but it is not like that

when I Create user foo or user bar their mailbox are set up as

/var/spool/imap/user/foo
/var/spool/imap/user/bar

How can I change this behaviour  and have the classical schema ?

/var/spool/imap/user/a/
/var/spool/imap/user/b/
/var/spool/imap/user/c/
/var/spool/imap/user/d/
.
.
.
/var/spool/imap/user/z/

I am using cyrus-imapd-2.4.17 on FreeBSD 9.1


thank you

Rick


----
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

&lt;/pre&gt;</description>
    <dc:creator>fddi</dc:creator>
    <dc:date>2013-06-01T11:16:15</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.mail.imap.cyrus/37404">
    <title>cyrus-imapd-2.4.17-caldav-beta5 released</title>
    <link>http://permalink.gmane.org/gmane.mail.imap.cyrus/37404</link>
    <description>&lt;pre&gt;We are pleased to announce the fifth beta release of Cyrus IMAP with 
integrated calendaring and contacts.  This is a security and bug fix 
release, with only two minor features added.  Sites that are using or 
testing any of the HTTP-based services are urged to upgrade to this release.

This code is based on the stable Cyrus 2.4.17 release with support for 
CalDAV, CardDAV and RSS added.  All of the standard Cyrus IMAP daemons 
and utilities should be considered production quality in this release, 
but the HTTP support (CalDAV, CardDAV and RSS) is in beta status.

You can download via HTTP or FTP:

http://cyrusimap.org/releases/cyrus-imapd-2.4.17-caldav-beta5.tar.gz
ftp://ftp.cyrusimap.org/cyrus-imapd/cyrus-imapd-2.4.17-caldav-beta5.tar.gz

Installation documentation will be found in doc/install-http.html in the 
distribution.

Thanks for your continued support, and we look forward to any and all 
feedback.

&lt;/pre&gt;</description>
    <dc:creator>Ken Murchison</dc:creator>
    <dc:date>2013-05-31T16:43:18</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.mail.imap.cyrus/37403">
    <title>Re: cyr_expire deadlock</title>
    <link>http://permalink.gmane.org/gmane.mail.imap.cyrus/37403</link>
    <description>&lt;pre&gt;

You probably will want to run reconstruct on that user's mailbox because 
the cyrus.index file may be corrupted at this time.  Also, you should 
upgrade to Cyrus v2.4.17 if you can.  There have been a large number of 
bugfixes since your version, one of which may be the cause of your 
deadlock.

 Andy----
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&lt;/pre&gt;</description>
    <dc:creator>Andrew Morgan</dc:creator>
    <dc:date>2013-05-21T21:14:57</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.mail.imap.cyrus/37402">
    <title>cyr_expire deadlock</title>
    <link>http://permalink.gmane.org/gmane.mail.imap.cyrus/37402</link>
    <description>&lt;pre&gt;Hi,

I am running cyrus imapd 2.4.11 on linux machine.

Today I had a deadlock involving cyr_expire and imapd process.

imapd was locked on (strace):

fcntl64(17, F_SETLKW, {type=F_WRLCK, whence=SEEK_SET, start=0, len=0}^C 
&amp;lt;unfinished ...&amp;gt;

where fd=17 is a user index file (lsof):

imapd     32314    cyrus   17u      REG        8,3     30944   10462461 
/var/spool/imap/domain/c/cenbench.pl/a/user/arek^dydo/cyrus.index

Unfortunetaly I did not check cyr_expire with strace, but lsof showed this:

cyr_expir 24356 cyrus    0u   CHR    1,3      0t0      509 /dev/null
cyr_expir 24356 cyrus    1u   CHR    1,3      0t0      509 /dev/null
cyr_expir 24356 cyrus    2u   CHR    1,3      0t0      509 /dev/null
cyr_expir 24356 cyrus    3u   CHR    1,3      0t0      509 /dev/null
cyr_expir 24356 cyrus    4u   CHR    1,3      0t0      509 /dev/null
cyr_expir 24356 cyrus    5u   REG    8,2      144 19196113 
/var/lib/imap/annotations.db
cyr_expir 24356 cyrus    6u   REG    8,2    13300 18911268 
/var/lib/imap/mailboxes.db
cyr_expir 24356 cyrus    7r  FIFO    0,5      0t0  5678136 pipe
cyr_expir 24356 cyrus    8w  FIFO    0,5      0t0  5678136 pipe
cyr_expir 24356 cyrus    9r  FIFO    0,5      0t0  5678137 pipe
cyr_expir 24356 cyrus   10w  FIFO    0,5      0t0  5678137 pipe
cyr_expir 24356 cyrus   11u   REG    8,2   171032 19196126 
/var/lib/imap/deliver.db
cyr_expir 24356 cyrus   12uR  REG    8,2        0 26961663 
/var/lib/imap/lock/domain/c/cenbench.pl/a/user/arek^dydo.lock
cyr_expir 24356 cyrus   13u   REG    8,3    30944 10462461 
/var/spool/imap/domain/c/cenbench.pl/a/user/arek^dydo/cyrus.index

There was 50 imapd processes (my upper limit) in locked on the same file 
and a single cyr_expire. After killing cyr_expire I had to manually kill 
all imapd processes to allow master to spawn new ones.

Not that my cyrus works on really, really slow machine. It is VM running 
under KVM with I/O access varying from 5 to 60MB/s (as shown by hdparm -t)

Please let me know what can I do to trace it better next time.

Regards,
Łukasz

----
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&lt;/pre&gt;</description>
    <dc:creator>Łukasz Michalski</dc:creator>
    <dc:date>2013-05-21T13:45:43</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.mail.imap.cyrus/37401">
    <title>Re: cyrus-imapd-2.4.17-caldav-beta4 released</title>
    <link>http://permalink.gmane.org/gmane.mail.imap.cyrus/37401</link>
    <description>&lt;pre&gt;Dave is correct.  The older imapd will show the calendar mailboxes to 
users in the LIST output.  If you want to hide them, you will have to 
install the new imapd binary. Otherwise, you could change the ACLs on 
the calendar mailboxes so that the user can't write to them, but they 
will still see them.


On 05/21/2013 06:55 AM, Sebastian Hagedorn wrote:


&lt;/pre&gt;</description>
    <dc:creator>Ken Murchison</dc:creator>
    <dc:date>2013-05-21T12:49:18</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.mail.imap.cyrus">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.mail.imap.cyrus</link>
  </textinput>
</rdf:RDF>
