Bug 1298228 - mock --new-chroot behaves differently running SRPM build vs running interactive shell
Summary: mock --new-chroot behaves differently running SRPM build vs running interacti...
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Fedora
Classification: Fedora
Component: ruby
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Jeroen van Meeuwen
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-01-13 14:39 UTC by Vít Ondruch
Modified: 2016-11-08 14:15 UTC (History)
21 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2016-11-08 14:15:12 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Ruby 12909 0 None None None 2016-11-08 14:15:11 UTC

Description Vít Ondruch 2016-01-13 14:39:06 UTC
Description of problem:
When I build ruby [1], the test suite fails using --new-buildroot.

$ mock -r ruby ruby-2.3.0-52.fc24.src.rpm

You can execute just the specific test using this command:

$ mock -r ruby --new-chroot --chroot '
su -c "cd /builddir/build/BUILD/ruby-2.3.0
make test-all TESTS=test/ruby/test_process.rb
" - mockbuild
'

<snip>

# Running tests:

.................................................F..............................................................................

Finished tests in 26.039477s, 4.9156 tests/s, 34.4477 assertions/s.

  1) Failure:
TestProcess#test_execopts_pgroup [/builddir/build/BUILD/ruby-2.3.0/test/ruby/test_process.rb:183]:
Errno::EPERM expected but nothing was raised.

128 tests, 897 assertions, 1 failures, 0 errors, 0 skips




Interestingly, trying to reproduce the error using interactive shell, there is no error:




$ mock -r ruby --new-chroot shell
<snip>

sh-4.3# su - mockbuild
[mockbuild@3e554eb942df4e10b123ae66f5c7efce ~]$ cd build/BUILD/ruby-2.3.0/
[mockbuild@3e554eb942df4e10b123ae66f5c7efce ruby-2.3.0]$ make test-all TESTS=test/ruby/test_process.rb

<snip>

# Running tests:

Finished tests in 25.797567s, 4.9617 tests/s, 34.8482 assertions/s.                       
128 tests, 899 assertions, 0 failures, 0 errors, 0 skips

ruby -v: ruby 2.3.0p0 (2015-12-25 revision 53290) [x86_64-linux]


I observe no error at all running --old chroot. What might the difference between interactive and noninteractive execution?

BTW this is the code which fails:

https://github.com/ruby/ruby/blob/v2_3_0/test/ruby/test_process.rb#L183



Version-Release number of selected component (if applicable):
$ rpm -q mock
mock-1.2.14-1.fc24.noarch


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:


[1] https://kojipkgs.fedoraproject.org//packages/ruby/2.3.0/52.fc24/src/ruby-2.3.0-52.fc24.src.rpm

Comment 1 Jan Kurik 2016-02-24 14:16:44 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 24 development cycle.
Changing version to '24'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora24#Rawhide_Rebase

Comment 2 Mikhail Campos 2016-07-18 11:13:37 UTC
I can reproduce the issue with mock-1.2.18-1

Comment 3 Mikhail Campos 2016-07-18 11:55:27 UTC
Seems like an issue of systemd:

Steps to reproduce:
1. echo "spawn('ruby -v', :pgroup=>2)" > test.rb
2. mock -r fedora-24-x86_64 --copyin test.rb /test.rb
3. su -
4. /usr/bin/systemd-nspawn -q -D /var/lib/mock/fedora-24-x86_64/root
5. -bash-4.3# su -c "/usr/bin/ruby /test.rb" - mockbuild
/test.rb:1:in `spawn': Operation not permitted - setpgid (Errno::EPERM)
	from /test.rb:1:in `<main>
6. /usr/bin/systemd-nspawn -q -D /var/lib/mock/fedora-24-x86_64/root su -c "/usr/bin/ruby /test.rb" - mockbuild
7. echo $?
0

It was expected the step 6 to end up with EPERM error as it was at step 5. Also, with :pgroup>=3 everything seems to be ok.

Comment 4 Miroslav Suchý 2016-07-25 14:55:06 UTC
So mock is only used to set up the chroot environment and it can be reproduced with plain systemd-nspawn. Changing component to systemd.

Comment 5 Zbigniew Jędrzejewski-Szmek 2016-08-31 11:04:46 UTC
I don't see a bug here. When run with nspawn directly, the pgid happens to be 2, so setpgid(…, 2) succeeds and is a noop, but when run in the other way, it happens to be different (19 here), and setpgid(…, 2) fails. So the difference is expected. I didn't look at the code but it seems that the ruby test suite assumes that 2 cannot be used as a pgid.

Comment 6 Vít Ondruch 2016-11-08 14:15:12 UTC
The test suite seems to be rather naive about the pgroup. I'm going to disable the test and report the issue upstream.

Closing this now.


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