On 2010-04-24 at 15:25:40 [+0200], Ingo Weinhold <ingo_weinhold@xxxxxx> wrote: > On 2010-04-24 at 14:43:59 [+0200], Andreas Färber <andreas.faerber@xxxxxx> > wrote: > > I've been playing with Subversion 1.7.0 (r936039, r937623) and for non- > > trivial stuff keep getting errors like this: > > > > svn: Can't open '/tmp/svn-tempfile.2.tmp': Too many open files > > svn: unable to open database file > > > > This is reproducible by running: > > > > svn co svn://anonsvn.mono-project.com/source/trunk/mcs > > > > As well as by subsequent `svn cleanup` and `svn up`, or by `svn > > upgrade` on a previous repository. With 1.6.x this didn't occur, so I > > suspect this is related to their upgrade of the repository format and/ > > or their use of SQLite (here 3.6.23.1). > > > > On Linux it would be possible to do something like `echo 1024 > /proc/ > > sys/kernel/file-max` or `ulimit -n 1024`. On Haiku the latter results > > in: > > sh: ulimit: cannot modify limit: Operation not allowed > > How can we achieve the equivalent on Haiku? Is there something like > > NR_FILE defined in the kernel? > > Haiku supports setrlimit() and RLIMIT_NOFILE, but not all RLIMIT_* > constants. bash's config.h doesn't define HAVE_RESOURCE, which is why > setrlimit() isn't used at all. Defining it may or may not work. Now I see, config-bot.h defines HAVE_RESOURCE. Very inventive. On 2010-04-24 at 16:37:08 [+0200], Jérôme Duval <korli@xxxxxxxxxxxxxxxx> wrote: > 2010/4/24 Andreas Färber <andreas.faerber@xxxxxx>: > > On Linux it would be possible to do something like `echo 1024 > > > /proc/sys/kernel/file-max` or `ulimit -n 1024`. On Haiku the latter > > results > > in: > > sh: ulimit: cannot modify limit: Operation not allowed > > How can we achieve the equivalent on Haiku? Is there something like > > NR_FILE > > defined in the kernel? > > ulimit has a soft value and a hard value. On Haiku, the hard limit is > 8192 and fixed, hence the Operation not allowed message. > You can however set the soft value with `ulimit -Sn 1024`. The specs for setrlimit() say that the appropriate privileges are required to raise the hard limit. Interestingly enough "ulimit -n ..." works fine under Linux when run as a normal user. I suspect we're doing something wrong. CU, Ingo