successful create but unsuccessful subscribe

Andrew Morgan morgan at
Wed Dec 19 16:45:36 EST 2012

On Wed, 19 Dec 2012, Frank Elsner wrote:

> On Wed, 19 Dec 2012 10:10:43 -0800 (PST) Andrew Morgan wrote:
>  [ ... ]
>> 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
> Ok, sounds good. On the mupdate master we already have the mupdate_* settings.
> Shall we put mupdate_* settings into the imapd.conf on the frontends too?

I have never set those on either mupdate master or frontends, although I 
have the defaults in imapd.conf commented out.  At least here with our 
systems, the defaults seem to be working well.

How would I know if I am reaching mupdate_workers_max?  Is that logged?


More information about the Info-cyrus mailing list