successful create but unsuccessful subscribe

[Frank Elsner]

On Wed, 19 Dec 2012 13:45:36 -0800 (PST) Andrew Morgan wrote:
> 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
> >>

  [ ... ]

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

We have tested with "mupdate ... prefork=1" on master and frontend(s) and it started 
ok, but we are facing an other problem:

On our RHEL system we have encreased the limit on processes and open files for the user
"cyrus" in /etc/security/limits.de/cyrus-imapd.conf by the lines 

cyrus            soft    nproc           3072
cyrus            soft    nofile          8192
cyrus            hard    nofile          8192

and we put a "ulimit -u 3072 -n 8192" right before the start of cyrus-master in
/etc/init.d/cyrus-imapd.

The running cyrus-master has these limits but the mupdate process only has 256 open files
allowed. This leads to 

Dec 20 11:44:34 mupdate-2 mupdate[13465]: accept failed: Too many open files
Dec 20 11:52:19 mupdate-2 mupdate[14098]: socket: Too many open files

Any pointer towards a solution is welcome.

Just for the records: The mupdate master has this legacy settings

mupdate_connections_max: 256
mupdate_workers_max: 512
mupdate_workers_start: 75
mupdate_workers_minspare: 75
mupdate_workers_maxspare: 120
mupdate_config: standard
mupdate_port: 3905


--Frank Elsner