Bug 732931 - regression introduced in mock after version 1.1.8
Summary: regression introduced in mock after version 1.1.8
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: libvirt
Version: 6.1
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: 6.1
Assignee: Libvirt Maintainers
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-08-24 07:58 UTC by manuel wolfshant
Modified: 2011-11-12 18:55 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-11-11 22:14:28 UTC


Attachments (Terms of Use)

Description manuel wolfshant 2011-08-24 07:58:46 UTC
Description of problem:
libvirt-0.8.7-18.el6.src.rpm cannot be built due to a failing test

Version-Release number of selected component (if applicable):
mock-1.1.10 and newer

How reproducible:
always

Steps to Reproduce:
1. mock -r epel-6-x86_64 libvirt-0.8.7-18.el6.src.rpm 
  
Actual results:
Build fails, build.log reveals:
TEST: commandtest                                                                                                                          
      ...................                      19  FAIL
FAIL: commandtest

Expected results:
TEST: commandtest                                                                                                                          
      ...................                      19  OK                                                                                      
PASS: commandtest  

Additional info:
Problem was seen while recompiling libvirt to add xen support.
mock-1.1.8 works; I have not tested mock-1.1.9

Comment 1 manuel wolfshant 2011-09-21 09:28:21 UTC
The regression still exists in mock 1.1.14, it fails exactly as before

TEST: sockettest
      ......................................   38  OK
PASS: sockettest

TEST: commandtest
      ..!!.!!!!!!!!!!!...                      19  FAIL
FAIL: commandtest

Comment 2 Clark Williams 2011-09-21 16:19:35 UTC
(In reply to comment #1)
> The regression still exists in mock 1.1.14, it fails exactly as before
> 
> TEST: sockettest
>       ......................................   38  OK
> PASS: sockettest
> 
> TEST: commandtest
>       ..!!.!!!!!!!!!!!...                      19  FAIL
> FAIL: commandtest

Can you turn on some debugging logic in the commandtest routine and see if we can get an idea why it's failing?

Comment 3 manuel wolfshant 2011-09-22 20:03:18 UTC
I get the following after adding the following lines just prior to "make check" in the specfile:

export VIR_TEST_VERBOSE=1
export LIBVIRT_LOG_OUTPUTS=3:stderr
export LIBVIRT_LOG_FILTERS="1:command"
export VIR_TEST_DEBUG=2

TEST: commandtest
 1) Command Exec test0 test                                           ... 22:55:24.762: 3468: info : libvirt vers
ion: 0.8.7, package: 18.el6.1 (Unknown, 2011-09-22-22:53:25, wolfy)
22:55:24.762: 3468: error : virCommandWait:1226 : internal error Child process exited with status 1.
22:55:24.762: 3468: info : libvirt version: 0.8.7, package: 18.el6.1 (Unknown, 2011-09-22-22:53:25, wolfy)
22:55:24.762: 3468: error : virCommandWait:1226 : internal error Child process exited with status 1.
OK
 2) Command Exec test1 test                                           ... OK
 3) Command Exec test2 test                                           ... FAILED
 4) Command Exec test3 test                                           ... FAILED
 5) Command Exec test4 test                                           ... OK
 6) Command Exec test5 test                                           ... FAILED
 7) Command Exec test6 test                                           ... FAILED
 8) Command Exec test7 test                                           ... FAILED
 9) Command Exec test8 test                                           ... FAILED
10) Command Exec test9 test                                           ... FAILED
11) Command Exec test10 test                                          ... FAILED
12) Command Exec test11 test                                          ... FAILED
13) Command Exec test12 test                                          ... FAILED
14) Command Exec test13 test                                          ... FAILED
15) Command Exec test14 test                                          ... FAILED
16) Command Exec test15 test                                          ... FAILED
17) Command Exec test16 test                                          ... OK
18) Command Exec test17 test                                          ... OK
19) Command Exec test18 test                                          ... OK
FAIL: commandtest

I am not sure how to generate a more verbose log. Please let me know if you need any other logs or instructions on how to retrieve any other useful info and I will be glad to help in debugging.
I can also upload all the logs if this helps.

Comment 4 Clark Williams 2011-09-22 20:16:56 UTC
W may need to get someone that knows the guts of libvirt, since I have no idea what is failing. 

We need to know why the child process started by test0 exited with a non-zero status. 

Oddly enough it looks like the test framework thinks test0 succeeded (printed Ok). And it also looks like you have five other tests that succeeded.

Comment 5 Clark Williams 2011-10-13 18:27:31 UTC
Just tried rebuilding the above libvirt version in my latest mock tree, but seeing the same result (commandtest failure). Really need someone that knows something about libvirt to give me a clue as to what's actually failing.

Comment 6 Akemi Yagi 2011-11-08 19:20:49 UTC
Probably not the solution per se .... but

Regarding the failure to build libvirt, this post addresses that:

http://www.redhat.com/archives/libvir-list/2011-July/msg00251.html

When I applied the referenced patch:

https://gitorious.org/~jfehlig/libvirt/libvirt-libxl/commit/f0e9dfeca967d05f23409c838619d9357d4f7d7f

building libvirt in mock-1.1.11 went through.

Comment 7 Clark Williams 2011-11-08 19:29:57 UTC
Manuel, 

Sounds like you need to cherry-pick the git commit from comment #6. 

Would you do so and confirm/deny that libvirt builds with the latest mock?

Comment 8 manuel wolfshant 2011-11-08 20:28:03 UTC
I will ASAP. Give me a day or two.

Comment 9 Clark Williams 2011-11-08 21:06:49 UTC
Thanks, no huge rush now that it's not a mock bug :)

Comment 10 Akemi Yagi 2011-11-08 21:18:28 UTC
I'm not sure if you can call this "not a mock bug" though. The fact is that earlier versions of mock did not have this issue.

By the way, I just tested with mock-1.1.16-1.el6. Building libvirt-0.8.7-18.el6_1.4 fails without the git commit and succeeds with it applied.

Comment 11 Clark Williams 2011-11-08 21:55:33 UTC
(In reply to comment #10)
> I'm not sure if you can call this "not a mock bug" though. The fact is that
> earlier versions of mock did not have this issue.
>

If your read the archive link above, you'll note the comment "recently changed to where a new process group is created by the builder". Mock did change to create a new process group for the chroot back when we were dealing with pty issues. So yeah, I call test failure, not mock bug.

Comment 12 Levente Farkas 2011-11-08 22:57:25 UTC
then why not change to rhel-6 and libvirt?

Comment 13 Clark Williams 2011-11-08 23:38:24 UTC
(In reply to comment #12)
> then why not change to rhel-6 and libvirt?

I don't understand what you're asking.

Comment 14 Levente Farkas 2011-11-09 08:23:35 UTC
if i understand correctly it's not a mock bug, but a libvirt's check bug. is it true?
if yes then please change this bug to libvirt (from mock) and rhel-6 (from epel-6).

Comment 15 manuel wolfshant 2011-11-10 10:05:11 UTC
I confirm that(In reply to comment #10)
> I'm not sure if you can call this "not a mock bug" though. The fact is that
> earlier versions of mock did not have this issue.

Well, I have mixed feelings about this. Just because a bug in an app did not manifest itself with a previous incarnation of mock does not mean that the application was not buggy.


> By the way, I just tested with mock-1.1.16-1.el6. Building
> libvirt-0.8.7-18.el6_1.4 fails without the git commit and succeeds with it
> applied.
I confirm this. Just did the same experiment but using mock-1.1.17 and obtained the same results. Compiles OK with the patch applied, fails in commandtest without the patch.

Comment 16 Clark Williams 2011-11-11 21:51:19 UTC
Almost certainly it's because when I cleaned up the PTY handling code I had to call os.setsid() which starts a new session and as a side effect creates a new process group. 

So I agree with Levente that this is a libvirt issue and not a mock issue. 

Changing the component to libvirt and OS to rhel-6

Comment 18 Eric Blake 2011-11-11 22:10:04 UTC
Per comment 6, libvirt has a spurious testsuite failure unless you backport commit f0e9dfeca; but this commit was added in upstream 0.9.0, therefore it is already present in the RHEL 6.2 build of libvirt.

Unless we need to backport this to RHEL 6.1.z, we can probably close this bug.

Comment 19 Dave Allan 2011-11-11 22:14:28 UTC
(In reply to comment #18)
> Per comment 6, libvirt has a spurious testsuite failure unless you backport
> commit f0e9dfeca; but this commit was added in upstream 0.9.0, therefore it is
> already present in the RHEL 6.2 build of libvirt.

Closing as CURRENTRELEASE.

Comment 20 Levente Farkas 2011-11-12 17:30:47 UTC
imho 6.2 is not release and until then it can't be closed...

anyway in 6.2 beta libvirt requires sanlock-devel which is not exists...

Comment 21 Akemi Yagi 2011-11-12 18:55:36 UTC
(In reply to comment #20)
> imho 6.2 is not release and until then it can't be closed...

I agree.

> anyway in 6.2 beta libvirt requires sanlock-devel which is not exists...

Are you sure? I was able to install libvirt-0.9.4-12.el6.x86_64 and that did not require sanlock-devel. At any rate, sanlock-devel is in the optional-6-beta repository.


Note You need to log in before you can comment on or make changes to this bug.