Hi, I am having trouble increasing the openfile limit in a default 
install of OpenBSD 4.6 x64 from the default setting of 128 to say 5000. 
I want to run Pound (reverse http proxy)  stably without it stopping at 
random times (Always seems to be the weekend) and to do that I need to 
crank up the openfile limit. I think Pound runs with the following 
account settings.... Type=deamon, user = _pound , group= _pound

I have tried tweaking a number of settings but haven't managed to get 
the setting above 1024.  Below are some of the settings we have tried 
changing but without complete sucess. I should say that my testing 
strategy is just to login as root and do a ulimit and see what is 
returned, I don't know how to test the openfile limit for a deamon account.

On a default install doing a ulimit -n  or -a  returns an openfile limit 
of 128

I know that if I do a ulimit -n 10000  the limit get's set at maximum of 
7030. I don't know if doing this change effects other users and I am 
pretty sure it doesn't survive a reboot.

I've done "sysctl kern.maxfiles=3000" for example but if I do a ulimit 
-n after I get a different result although I can't remember what it was
I also tried editing the sysctl.conf file and put the kern.maxfiles 
entry in there but had similar results !

I've edited the login.conf file and changed the staff, default and the 
daemon entries eg :openfiles-cur=2222:\ and then rebooted but the 
highest I could get the openfile limit to is 1024

Could someone help ?

Thanks
Keith

[ message continues ]

-- 
jakemsr@sdf.lonestar.org
SDF Public Access UNIX System - http://sdf.lonestar.org

[ message continues ]

If you start it from a shell, it uses the class for the account you've
logged in as.

If you start it from /etc/rc.local, unless you do something with su or
sudo, it uses the class daemon.

So you need to adjust openfiles-cur for the class of the account you're 
starting it from. If starting it from a shell, make sure you use a new

This limit is from kern.maxfiles sysctl. Either adjust it with sysctl(8)

This is lowering things from the default (7030), at least on i386
and amd64.

[ message continues ]

Thanks for reply, it was the openfiles-cur that had been causing us 
problems. I've upped the limit so something like 10000 and everything 
seems fine now
.
Thanks
Keith


[ message continues ]

You probably don't need to touch this.  Indeed, you *lowered* it:

$ sysctl kern.maxfiles
kern.maxfiles=7030
$

Note the kern.maxfiles is the upper-bound on open files in the
*entire* system and not a limit on the number of file descriptors in a
process!  You don't need to touch that unless/until you get ENFILE

This is the right place, you just didn't consider the -cur vs -max
distinction.  By default, openfiles-max=1024.  If you want cur to be
2222 then you need to either raise both (by just setting
openfiles=2222) or explicitly set openfiles-max to at least 2222.


Philip Guenther

[ message continues ]

Hi, I got another question regarding this matter.
How is the openfile count accounted for? Is it per process, per user, 
per shell? How does this work?

I recently had problems when running rtorrent, which used about 100 file 
descriptors (sockets). Pjsua then failed with "Too many open files" 
(sockets, too), although it should not use more then three sockets.

I also once increased openfile-cur to 1024 for one shell, started an 
appilcation using many sockets (>200) and then applications on other 
shells with openfile-cur=128 would fail.



Christopher

[ message continues ]

There is an overall system limit, set with sysctl kern.maxfiles=n,
current in-use fds can be displayed with sysctl kern.nfiles.

There is also a per-process limit.  Processes inherit the limits from
the parent process, but can change the lmits via system calls (with
restrictions for non-seuperuser processes). 

Reading what you described above, it looks like you hit the
system-wide limit. 

	-Otto

[ message continues ]

On 05/07/10 11:20, Otto Moerbeek wrote:
 > There is an overall system limit, set with sysctl
 > kern.maxfiles=n,
 > current in-use fds can be displayed with sysctl kern.nfiles.
 >
 > There is also a per-process limit.  Processes inherit the limits from
 > the parent process, but can change the lmits via system calls (with
 > restrictions for non-seuperuser processes).
 >
 > Reading what you described above, it looks like you hit the
 > system-wide limit.

Ok, so two processes started from the same shell won't take away
descriptors from each other?

for example:

$ ulimit -n 50
$ use_40_fds &
$ use_maby_fds   # <- this process can use 10 or 50 fds ??


thanks,

Christopehr

[ message continues ]