Description of problem:
failed run in beaker with a bunch of testcases which passed in rhts, and run failed testcase separately in beaker could pass.
Version-Release number of selected component (if applicable):
# uname -a
Linux dhcp-65-195.nay.redhat.com 188.8.131.52-174.fc12.i686.PAE #1 SMP Mon Dec 21 06:04:56 UTC 2009 i686 i686 i386 GNU/Linux
# rpm -qa|grep beaker
Steps to Reproduce:
1. a bunch of testcases could pass in rhts on all arches:
2. the same bunch of testcases failed run in beaker:
3. select failed testcases and run it one by one could pass in beaker:
the test result should same with rhts ——pass.
seems it's often failed with batch run.
Have you considered this could be a problem with the test?
If it runs fine on its own, it is likely an interference with previous test(s) where some of them did not do a proper clean up, what's supported by fact that the nfs service who refuses to start. Have you checked logs?
Did the test in RHTS run in the same order and with same parameters?
(In reply to comment #1)
> Have you considered this could be a problem with the test?
> If it runs fine on its own, it is likely an interference with previous test(s)
> where some of them did not do a proper clean up, what's supported by fact that
> the nfs service who refuses to start. Have you checked logs?
> Did the test in RHTS run in the same order and with same parameters?
In my opinion, if these testcases didn't do a proper clean up, they should also fail in rhts, but the true is they all passed in rhts with batched run, pls check the rhts job links.
Could it be that there need different or extra mechanism to create testcase run by beaker against rhts?
Correct me if I'm wrong, thanks.
since we're actively pushing to kill off legacy RHTS, I'd like to get status on this bug. Either work it as a blocker or let's move it into qe-hotbeakerbugs tracker.
Is this really a regression? Should we block RHTS decommision for this? Is QE going to be able to continue testing when RHTS is dead?
(In reply to comment #3)
> Hi guys,
> since we're actively pushing to kill off legacy RHTS, I'd like to get status on
> this bug. Either work it as a blocker or let's move it into qe-hotbeakerbugs
> Is this really a regression? Should we block RHTS decommision for this? Is QE
> going to be able to continue testing when RHTS is dead?
I always run regression test with the bunch of testcases against nfs-utils package, and these passed in rhts before. So I think it will be a big problem to me if I can't run these regression testcases in beaker to deal with nfs-utils errata while rhts is dead.
And these testcases all have clean up phase that work well in rhts, do I need to re-spent time to re-check them again? In fact, I don't know where cause the problem in testcase and most of them created and owned by different engineer.
So pls investigate if it's a beaker bug. If not pls give me detail feedback why they are passed in rhts before and failed in beaker now and how to modify testcase accordingly?
Understood. I'm taking this to beaker-dev-list.
The problem is caused by nfs daemon which can not be killed except with kill -9. The service is not restarted and the tests are failing. And once started, it is not killable again.
I have asked steved for help, but even he could not get anything meaningful from the machine. He indicated the problem may lay with kernel:
<steved> mcsontos: Its not clear... It appeared the kernel process got into some funky state where they were no longer accepting signals....
<steved> mcsontos: the fact that things are now working normally makes think is something in the kernel...
I will try to isolate the problem.
Thanks for looking into this. From your description it sounds like we should have the same issue under legacy RHTS right?
Not necessarily. It must be triggered by either harness or configuration. And something in configuration may come e.g. from system installation.
So what are the next steps here?
Finally it boiled down to problems with TTY: 'service nfs <OP>' does not work very well without one.
Testing with modified harness ( Bug 666980 )
Running test in compatible mode helps:
This will be delivered within next update window.