This kind of message started to fill my log probably month ago:

Mar 12 07:20:08 mail dovecot: pipe() failed: Too many open files

I'm using dovecot on small home mail server 10 users. I thought this is
maybe because I'm using maildir, IMAP
and my daemon did have default openfiles.
I raised openfiles to 2048, but  looks like after month I'm in the same
situation.

login.conf excerpt:

dovecot:\
        :ignorenologin:\
        :datasize=infinity:\
        :maxproc=infinity:\
        :openfiles-cur=2048:\
        :stacksize-cur=8M:\
        :localcipher=blowfish,8:\
        :tc=default:

My question is, what settings are you using in "real" life?
Is standard setting for daemon class insufficient for certain servers?
If you did get this error message, which server was involved?

Thank you,

-- 
  ico

What version of OpenBSD are you using? What version of dovecot? From
ports/packages, or did you roll your own?

I had a similar problem back in December of last year, and a commit was
made to OpenBSD 4.0 -STABLE ports tree that fixed my problems ever
since. I'm using dovecot-1.0.rc15

- Seth

PS - Thanks again, Brad! Works like a champ now.

had this same problem before upgrading to the 1.0rc15 package. the 
earlier rc's are no good for fds.

cheers,

Hi Stefan,


Does dovecot actually run under this login class?

What does `sysctl kern.maxfiles` say?

HTH... Nico

Hello Nico,

thanks for quick reply.

Does dovecot actually run under this login class?
I did modify login.conf
# cap_mkdb /etc/login.conf
than kill -HUP "_dovecot_PID"

I hope that's enough to run it under dovecot class. How do I find out?


What does `sysctl kern.maxfiles` say?



$sysctl kern.maxfiles
kern.maxfiles=1772

It's less than my setting in login.conf, but this should be enough anyway.

-- 
  ico

First, check if all is well:
sudo su -c dovecot root -c 'ulimit -a'

You might want to start dovecot like this:
su -c dovecot root -c '/usr/local/bin/dovecot'

(or whatever the path to the dovecot binary is)

Remember, I don't run dovecot. This info comes from my MySQL install.

kern.maxfiles is system wide and independent of any login class. dovecot
might hit this limit. I'd try with 17720 first.

HTH... Nico

If you perform a `ps aux` you will see what user dovecot is running as, that's
the user whose class you want to check.

Then `grep username /etc/master.passwd` (I presume you can sudo) and the 5th

You might find dovecot is not running at the user you think it is (or at least
isn't in the class you think it is).

As a side note I have noticed that Dovecot can be a bit fd hungry.

HTH
Dave

ico@mail ~ $sudo ps waxu | grep dovecot
root     26251  0.0  0.2   620   912 ??  Ss    15Jan07
0:55.12/usr/local/sbin/dovecot
_dovecot 13219  0.0  0.3   560  1580 ??  S      8:02AM    0:00.11 pop3-login
_dovecot  3653  0.0  0.3   652  1584 ??  S      8:02AM    0:00.12 pop3-login
_dovecot  9416  0.0  0.3   540  1564 ??  S      8:02AM    0:00.11 imap-login
root     32241  0.0  0.2   592  1012 ??  S      8:02AM    0:00.09dovecot-auth
_dovecot 16174  0.0  0.3   576  1564 ??  S      8:12AM    0:00.11 pop3-login
_dovecot 19555  0.0  0.3   520  1592 ??  S     10:29AM    0:00.01 imap-login
_dovecot 13961  0.0  0.3   504  1564 ??  S     10:29AM    0:00.01 imap-login
ico      22226  0.0  0.1   448   504 p6  S+    10:30AM    0:00.00 grep
dovecot

ico@mail ~ $sudo lsof -p 26251 | wc -l
      38

Right now nobody is connected. I can imagine if someone connects and wants
to read bigger  maildir through IMAP, it can be more than default 64.

My daemon class is now on 512 files. Removed dovecot class.
I'll try this for a while.

Thanks

-- 
  ico

That's probably the less preferable option.  The best way would be to leave the
dovecot class, make sure the _dovecot user is allocated to that class (Nico's
post will show you that) and then modify the limits for that class only -
modifying the daemon class will affect all processes that come it.

Dave

I'm not sure, because I haven't noticed  what's opened, when limits where
reached.
If Maidirs are the case, _dovecot user certainly doesn't have rights to read
Maildir/inbox. It's all vmail:vmail with 600 permissions on files. Initially
dovecot is running as root. I'm sure it's dropping privileges when possible,
but reading Maildirs is probably not the case.
If it's root, root is daemon class. That's why I removed dovecot class.
Looks to me, that _dovecot processes are there for authentication. Not sure
though.

-- 
  ico