dovecot - Aug 2007 - Dovecot should raise the limit of file descriptors at startup...

We've run into a situation where the Dovecot master process
"dovecot"
runs out of file descriptors on Solaris 10 since the default is
only 256:

# plimit 1
1:      /sbin/init
   resource              current         maximum
  time(seconds)         unlimited       unlimited
  file(blocks)          unlimited       unlimited
  data(kbytes)          unlimited       unlimited
  stack(kbytes)         8192            unlimited
  coredump(blocks)      unlimited       unlimited
  nofiles(descriptors)  256             65536
  vmemory(kbytes)       unlimited       unlimited



Output from "pfiles" after we raised the limit manually:

# pfiles 26378 | head -10
26378:  /ifm/sbin/dovecot -c /etc/dovecot.conf
  Current rlimit: 16384 file descriptors
   0: S_IFCHR mode:0666 dev:327,15 ino:18128 uid:0 gid:3 rdev:13,2
      O_RDONLY|O_LARGEFILE
      /export/zones/dovecot/root/dev/null
   1: S_IFCHR mode:0666 dev:327,15 ino:18128 uid:0 gid:3 rdev:13,2
      O_RDONLY|O_LARGEFILE
      /export/zones/dovecot/root/dev/null
   2: S_IFCHR mode:0666 dev:327,15 ino:18128 uid:0 gid:3 rdev:13,2
      O_RDONLY|O_LARGEFILE
# pfiles 26378 | tail -10
 243: S_IFIFO mode:0000 dev:324,0 ino:2038192 uid:0 gid:0 size:0
      O_RDWR|O_NONBLOCK FD_CLOEXEC
 246: S_IFIFO mode:0000 dev:324,0 ino:2048002 uid:0 gid:0 size:0
      O_RDWR|O_NONBLOCK FD_CLOEXEC
 247: S_IFIFO mode:0000 dev:324,0 ino:2048441 uid:0 gid:0 size:0
      O_RDWR|O_NONBLOCK FD_CLOEXEC
 258: S_IFIFO mode:0000 dev:324,0 ino:2042076 uid:0 gid:0 size:0
      O_RDWR|O_NONBLOCK FD_CLOEXEC
 459: S_IFIFO mode:0000 dev:324,0 ino:1311426 uid:0 gid:0 size:0
      O_RDWR|O_NONBLOCK FD_CLOEXEC

Perhaps the Dovecot master process should raise it's own limit to the
allowed maximum when it starts? (getrlimit()+setrlimit()), or be
user configurable?

Has this been discussed somewhere before?

- Peter

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 185 bytes
Desc: OpenPGP digital signature
URL:
<http://dovecot.org/pipermail/dovecot/attachments/20070821/a83d2f60/attachment-0002.bin>

On Tue, 2007-08-21 at 15:08 +0200, Peter Eriksson wrote:
> Perhaps the Dovecot master process should raise it's own limit to the
> allowed maximum when it starts? (getrlimit()+setrlimit()), or be
> user configurable?
I guess this could be a good idea. Added to v1.1: 
http://hg.dovecot.org/dovecot/rev/0e08960275f8
http://hg.dovecot.org/dovecot/rev/c6d6ce742a82

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL:
<http://dovecot.org/pipermail/dovecot/attachments/20070824/1f20cccb/attachment-0002.bin>

Timo Sirainen escribi?:
> On Tue, 2007-08-21 at 15:08 +0200, Peter Eriksson wrote:
>> Perhaps the Dovecot master process should raise it's own limit to
the
>> allowed maximum when it starts? (getrlimit()+setrlimit()), or be
>> user configurable?
> 
> I guess this could be a good idea. Added to v1.1: 
I'm sorry, but having arbitrary programs change limits set by a system
policy because they feel like it, doesn't look like a good idea to me.
When I configure a policy I expect it to stay that way, and if it
backfires it's my mess to fix :) You could warn about the limit being
too low in the log at startup though.

Regards,
-- 
Angel Marin
http://anmar.eu.org/