successful create but unsuccessful subscribe

Andrew Morgan morgan at
Wed Dec 19 13:10:43 EST 2012

On Wed, 19 Dec 2012, Kerstin Espey wrote:

> On 14.12.2012 20:35, Dan White wrote:
>> See if setting
>> allowallsubscribe: 1
>> on your frontend makes any difference.
> Unfortunately it does not.
> I have reviewed the whole configuration, shortened the config on the
> mupdate master, but nothing helped.
> Now I have reduced the number of preforked mupdate process on the master
> from 5 to 1 - this does the job.
> Increasing the number of preforked processes again leads to the
> well-known misbehaviour. Decreasing again, everything is fine.
> Is this a known behaviour?

This sounds like a bug, either in documentation or behavior.  I could not 
find an existing bug report for it.  Would you be willing to create a bug 
report at

> Our setting on the master is now:
> mupdate       cmd="/usr/lib/cyrus/bin/mupdate -m"
> listen="<ipaddress>:3905" prefork=1 maxchild=20
> How long does it scale?
> Thanks to everybody and I wish you a Merry Christmas!

I don't know why, but we have always operated with prefork=1 here.  As far 
as I can tell, it never runs more than 1 mupdate process.  That single 
mupdate process has 15 connections in total from our 3 frontend servers. 
There doesn't seem to be a need for it to spawn additional mupdate 
processes.  Now that I look closer, I see that mupdate is threaded...

We have 3 frontends and 3 backends.  Each backend has about 20,000 users 
on it.

Here is my cyrus.conf entry on the mupdate master:

   mupdate       cmd="/usr/local/cyrus/bin/mupdate -m" listen="3905" proto="tcp4" prefork=1

and on the frontends:

   mupdate       cmd="/usr/local/cyrus/bin/mupdate" listen="3905" proto="tcp4" prefork=1

Hmm, there is no manpage for mupdate either!  Digging around in the source 
code shows that there are configuration options for mupdate in imapd.conf, 
such as:

        mupdate_workers_max: 50
             The maximum number of mupdate worker threads (overall)

        mupdate_workers_maxspare: 10
             The maximum number of idle mupdate worker threads

        mupdate_workers_minspare: 2
             The minimum number of idle mupdate worker threads

        mupdate_workers_start: 5
             The number of mupdate worker threads to start

So the usual process controls in cyrus.conf don't really apply anyways!


More information about the Info-cyrus mailing list