[Swan-dev] testing/utils/kvmresults.py has a problem
andrew.cagney at gmail.com
Fri Sep 4 00:42:36 UTC 2020
On Thu, 3 Sep 2020 at 17:21, D. Hugh Redelmeier <hugh at mimosa.com> wrote:
> | From: Andrew Cagney <andrew.cagney at gmail.com>
> | So why is that log file so big?
> | Hmm ..., TCP. Hmm ...
> | perhaps you need the custom kernel with the upstream tcp fixes?
> | > -rw-rw-r--. 1 build build 278 Sep 3 03:27 RESULT
> | > -rw-rw-r--. 1 build build 0 Sep 3 03:27 nic.console.diff
> | > -rw-rw-r--. 1 build build 1738 Sep 3 03:27 east.console.diff
> | > -rwxr-xr-x. 1 build qemu 656477 Sep 3 13:21 east.pluto.log
> | > -rwxr-xr-x. 1 build qemu 34470761890 Sep 3 13:21 road.pluto.log
> Notice the timestamps.
> All tests had finished about 9:00.
Looking in TESTLIST, ikev2-tcp-25-rw-nat is the second last good test.
kvmrunner may have crashed but still given the impression that
everything finished (the last test is an openbsd interop, it probably
should be marked wip).
> I didn't run testing/utils/kvmresults.py until about 13:00. That's when
> kvmresults crashed. Plenty of time for the log to grow between 9:00 and
> 13:00. I don't actually know if the logfile was growing all that
> time, but it would be hard to write that much in the timeslot allotted
> to a single test.
> I don't understand why machines don't get rebooted. That would surely
> stop this.
They get rebooted / shutdown lazily. If this was the last tes the VMs
would still be running.
> | I suspect that's more of a symptom.
> | The following would have happened:
> | - road booted
> | - pluto started and tests run
> | - pluto on road left running and, presumably, spewing log messages
> | even though, pretty much immediately, kvmrunner tries to load the log
> | file, it's already too late.
> I didn't notice that kvmrunner had a problem. Would you like me to
> | First shutting down road likely wouldn't help.
> Why not?
If, by the time the test as finished, pluto.log is huge, rebooting
won't make any difference.
I think you need the hacked tcp kernel (I sent a link off list).
One of the kernel bugs I found was with EAGAIN being returned when it shouldn't.
> I don't know/remember how to shut down the VMs via ssh so I stopped
> things by rebooting the host. (My test machine is at home but I'm
More information about the Swan-dev