Bug 1298228 - mock --new-chroot behaves differently running SRPM build vs running interactive shell
mock --new-chroot behaves differently running SRPM build vs running interacti...
Product: Fedora
Classification: Fedora
Component: ruby (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Jeroen van Meeuwen
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2016-01-13 09:39 EST by Vít Ondruch
Modified: 2016-11-08 09:15 EST (History)
21 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2016-11-08 09:15:12 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Ruby 12909 None None None 2016-11-08 09:15 EST

  None (edit)
Description Vít Ondruch 2016-01-13 09:39:06 EST
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


# Running tests:


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

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


# 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:


Version-Release number of selected component (if applicable):
$ rpm -q mock

How reproducible:

Steps to Reproduce:

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 09:16:44 EST
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:
Comment 2 Mikhail Campos 2016-07-18 07:13:37 EDT
I can reproduce the issue with mock-1.2.18-1
Comment 3 Mikhail Campos 2016-07-18 07:55:27 EDT
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 $?

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 10:55:06 EDT
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 07:04:46 EDT
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 09:15:12 EST
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.