Small test fixes

[galderz]

Contains a couple of fixes:

First it fixes process builder output in tests to show errors, otherwise reasons for test failures are not shown.

Second, I'm seeing some random failures like:

Process Process[pid=5119, exitValue=0] has leading size 12
Process Process[pid=5118, exitValue=0] has leading size 12
[ERROR] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 14.029 s <<< FAILURE! - in TestHooks
[ERROR] TestHooks.TestOne(Path)  Time elapsed: 14.028 s  <<< FAILURE!
org.opentest4j.AssertionFailedError: expected: <true> but was: <false>
    at TestHooks.TestOne(TestHooks.java:118)

The trees value is not used, so it could be dead code eliminated. Using the value seems to be enough to avoid DCE and get the GC logic working as the test expects. It might not be failproof but seems to work for now. On my server this was failing every other run.

[galderz]

The reason for fixing stderr is because without consuming that, I couldn't see the reason why the tests were initially failing. That reason was /var/lib/sss/pipes/nss.

[galderz]

E.g.

error line 0 = Exception in thread "main" com.redhat.jigawatts.SssPipeNssFileException: criu do not work if /var/lib/sss/pipes/nss exists. By default we throw exception, if we should try, set following variable to `ignore`. Use `force` to let us delete it and resore it afterwards. Set `fierce`, similar to force, but ignoring any exceptions;-Djigawatts.ssspipesnss/$JIGAWATTS_SSSPIPESNSS: null
error line 1 =  at com.redhat.jigawatts.SssPipeNssFileException.closeSssNssFile(SssPipeNssFileException.java:16)
error line 2 =  at com.redhat.jigawatts.Jigawatts.preNativeActions(Jigawatts.java:136)
error line 3 =  at com.redhat.jigawatts.Jigawatts.saveTheWorld(Jigawatts.java:81)
error line 4 =  at com.redhat.jigawatts.Jigawatts.saveTheWorld(Jigawatts.java:87)
error line 5 =  at RandomTest.TestRandomCheckpoint(RandomTest.java:73)
error line 6 =  at RandomTest.main(RandomTest.java:139)

[galderz]

Fixed the brackets via an update to the relevant commit.

[judovana]

Thax. As for the streams, my original idea was more to have one thread launched for stderr and one for stdout, and wait for both. But I agree it may be overcompelx for the case. WDYT?

The, /var/lib/sss/pipes/nss is troublemaker. To have hem read both in seqence can lead to more then jsut a confusion I'm not in favour of that.

[galderz]

Thax. As for the streams, my original idea was more to have one thread launched for stderr and one for stdout, and wait for both. But I agree it may be overcompelx for the case. WDYT?

Ah I see what you mean now. Yeah I think it sounds a bit too complex for no specific reason. This is all done in testing so you're not worried about its performance.

The, /var/lib/sss/pipes/nss is troublemaker. To have hem read both in seqence can lead to more then jsut a confusion I'm not in favour of that.

What is it "more" that you are worried about? We need to be clear here.

[judovana]

Well to not miss any output :)

[judovana]

I had added you to comaintainers, so you ar enot blocked by my absence