Test scenario for sysctl kern.maxfiles

Peter Holm peter at holm.cc
Thu Mar 6 11:23:31 UTC 2014

On Wed, Mar 05, 2014 at 10:08:49AM -0700, Alan Somers wrote:
> On Wed, Mar 5, 2014 at 1:58 AM, Peter Holm <peter at holm.cc> wrote:
> > Here's an attempt to verify that increasing kern.maxfiles works as
> > expected.
> >
> > http://people.freebsd.org/~pho/kern_descrip_test-v3.diff
> > --
> > Peter
> 1) done should be of type "static volatile sig_atomic_t", not int,
> because it's set by signal handlers.

Yes, that is nicer (I learned something new today :-). But the use
here works because there is a call to usleep(3) after each test,
forcing the compiler to reload the "done" variable.

> 2) using atexit() to register a cleanup routing is a hack.  No doubt

Why do you say that using atexit(3) is a hack?

> you already noticed that it's difficult to use Kyua's builtin cleanup
> capabilities because of the need to pass the value of oldmaxfiles.  I
> too have experienced that frustration.  Is there any way to pass
> values from the body of a testcase to its cleanup?  Using
> atf_tc_set_md_var() would be one way, but the man page suggests that
> that function cannot be called from the body.  Julio, is there a
> better way to do this?
> 3) Why do you openfiles(oldmaxfiles + 50, 0) instead of just
> openfiles(oldmaxfiles) ?  It seems that the latter would also verify
> the assertion.

The idea is to test "expansion" -> expand maxfiles to maxfiles +
1000 and test "more than was possible before". But that of cause
only works on a moderately loaded host.

> 4) openfiles(oldmaxfiles + 50, 0) will fail if there are already 950
> open files.  A quick check on freefall showed that kern.openfiles was
> 935.  Perhaps you should try opening openfiles(oldmaxfiles -
> kern.openfiles + 50, 0).  That wouldn't be perfect, due to races, but
> it would be better.

Yes I agree, that would be better.

Now this raises an interesting question for me: Which environment do
you guys expect ATF to run in? If it is hosts like freefall, any
resource hogging tests are out of the question I would think.


More information about the freebsd-testing mailing list