Page MenuHomeFreeBSD

racct: Add some tests
Needs ReviewPublic

Authored by cyril_freebsdfoundation.org on Jun 29 2021, 10:58 PM.
Tags
None
Referenced Files
Unknown Object (File)
Nov 22 2024, 6:01 PM
Unknown Object (File)
Nov 12 2024, 3:29 PM
Unknown Object (File)
Nov 12 2024, 1:21 PM
Unknown Object (File)
Nov 12 2024, 3:50 AM
Unknown Object (File)
Nov 11 2024, 1:25 PM
Unknown Object (File)
Nov 10 2024, 7:20 PM
Unknown Object (File)
Nov 10 2024, 11:18 AM
Unknown Object (File)
Nov 10 2024, 12:46 AM
Subscribers
None

Details

Reviewers
markj
Summary

This revision adds some tests for racct. They test the upcoming addition of racct to POSIX shared memory as well as the upcoming fixes to pcpu and cputime calculations.

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Skipped
Unit
Tests Skipped

Event Timeline

Overall this looks good to me. There are some stylistic nits which I pointed out.

What do you think of adding a short test to verify the runtime accounting? It might be easiest to write a short C program which loops for N seconds (with N == 3 or so, we don't want tests that take too long to run) and exits. alarm(3) would be a useful function there.

tests/sys/racct/Makefile
2

This can be removed, it's a holdover from when we used Subversion. It's not useful anymore.

tests/sys/racct/racct_jail.sh
6 ↗(On Diff #91531)

It's good form to also set descr to a sentence describing what the test is verifying.

97 ↗(On Diff #91531)

Rather than checking exit statuses manually, you might consider using atf-check(1).

121 ↗(On Diff #91531)

Since you're defining names for the parameters, it's a bit nicer to make them locally-scoped:

local jailname i size

jailname=$1
...
135 ↗(On Diff #91531)

A simpler way to write these kinds of loops is

for i in $(seq 1 $max); do
...
done

Then you don't need to initialize $i or increment it.

cyril_freebsdfoundation.org edited the summary of this revision. (Show Details)

I have added a test for cputime and pcpu which takes 4 seconds to complete. Since it is a loop that executes another process, the calculations involved are inexact (compared to a loop that simply spins) and we cannot expect a precise value for these measurements.

I have also added another interesting test, for maxproc. It is a currently failing test, but I'm not sure why. The test uses a process to create 6 children, but expects to fail on the last one. In my manual testing, I have found that it instead fails on the 5th child even though maxproc is set to 5 (the parent process does not count as one of the processes, since it is executed using jexec). We can change this to atf_expect_fail, if needed.

Remove unnecessary quoting and ignore error messages.