Stas Bekman <[EMAIL PROTECTED]> writes: > Gisle Aas wrote: > > Stas Bekman <[EMAIL PROTECTED]> writes: > > > >>>Did not think about that. Yes, the default limit is 60 opened files > >>>on this machine. I ran 'ulimit -n 1024' and then 'make test' again. > >> > >>Great. > >> > >>I wish we could somehow automate this diagnostics to save the wasted > >>time for the report-response email cycle. As you can see it's not the > >>first time we get it reported. Ideas? > > Can't t/TEST check the output of 'ulimit -n' and verify that it is > > high enough? > > Good idea, Gisle. But will it work everywhere where perl runs?
I'm quite sure it does not work on Windows. > > Alternatively try the BSD::Resource module? > > So does it mean that 'ulimit -n' may not work? ulimit is usually a shell builtin and shells vary. The POSIX ulimit [1] is very limited. [1] http://www.opengroup.org/onlinepubs/009695399/utilities/ulimit.html > > For our mail filtering product (PureMessage) we also had problems with > > reports caused by this limit and we fixed it by embedding this code in > > the server core: > > if (getrlimit(RLIMIT_NOFILE, &rlim) == 0 > > && rlim.rlim_cur != RLIM_INFINITY > > && rlim.rlim_cur < rlim.rlim_max) > > { > > rlim.rlim_cur = rlim.rlim_max; > > if (setrlimit(RLIMIT_NOFILE, &rlim) != 0) { > > warn("Can't max RLIMIT_NOFILE limit: $!"); > > } > > } > > This tries to move the soft limit for open files as high as it can > > go. > > nice, but requires BSD::Resource which is not available on all > platforms I believe. But certainly worth a try. This is actually C code and should work on systems that have {get,set}rlimit. --Gisle -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
