[Dovecot] 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
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
On Fri, 2007-08-24 at 20:51 +0300, Timo Sirainen wrote:
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
And fixes.. http://hg.dovecot.org/dovecot/rev/5ebf96e37a39
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/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Mon, Aug 27, 2007 at 09:07:10AM +0200, Angel Marin wrote:
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
[...]
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
I thunk you still can set "hard" limits if you don't want applications overriding your policy. To me, overriding a soft limit does make sense on an application-by-application basis.
Regards
- -- tomás -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFG0qdBBcgs9XrR2kYRAsKvAJ9OHUCVLgluepIOH138jroHA7bsLwCfQ/OC 7yU+j+VTNXuJPKuFKkSn3Zg= =lVx0 -----END PGP SIGNATURE-----
participants (4)
-
Angel Marin
-
Peter Eriksson
-
Timo Sirainen
-
tomas＠tuxteam.de