Bug 479556 - Mock don't build anything
Summary: Mock don't build anything
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora EPEL
Classification: Fedora
Component: mock
Version: el5
Hardware: All
OS: Linux
low
urgent
Target Milestone: ---
Assignee: Clark Williams
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: ActualBug
Depends On:
Blocks: 449396 503158 548713 557424
TreeView+ depends on / blocked
 
Reported: 2009-01-11 09:02 UTC by Frank Büttner
Modified: 2013-01-10 05:00 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-05-08 15:27:59 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
The stacktrace output. (34.42 KB, text/plain)
2009-07-09 13:12 UTC, Frank Büttner
no flags Details

Description Frank Büttner 2009-01-11 09:02:25 UTC
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5 (.NET CLR 3.5.21022)

When I try to run mock nothing will happens.
Version: mock-0.9.11-1.el5

Reproducible: Always

Steps to Reproduce:
1. build an srpm
2. try to build it via  mock qtiplot-0.9.7.4-8.fc11.src.rpm or
   mock -r distname qtiplot-0.9.7.4-8.fc11.src.rpm

Actual Results:  
no results.
After calling it you get only the console back, with no output.

Expected Results:  
Some error messages or working build environment.

Comment 1 Jesse Keating 2009-02-06 00:37:58 UTC
Try passing mock -v -r <distname> --rebuild <srpm>

Comment 2 Frank Büttner 2009-03-27 22:44:39 UTC
this will  result only in this:
[frank@homer EL-5]$ mock -v -r epel-5-i386 --rebuild qwt-5.0.2-5.el5.src.rpm
[frank@homer EL-5]$

Comment 3 Michael Stahnke 2009-03-28 19:41:58 UTC
If you use mock-0.9.14-1.el5 do you still have this issue?

Comment 4 Frank Büttner 2009-03-28 20:37:41 UTC
Yes it is mock-0.9.14-1.el5.

Comment 5 Clark Williams 2009-07-05 14:34:13 UTC
first, try adding --verbose to the command line:

$ mock --verbose -r distname --rebuild qtiplog-0.9.7.4-8.fc11.src.rpm

if you still don't get any output, please attach your srpm (or post a link where we can download it) so we can debug with the actual srpm.

Comment 6 Clark Williams 2009-07-05 14:35:51 UTC
oh, another thing: have you tried building any other srpm? if you can't build anything, then it's something specific to your setup, whereas if you can't build just the qtiplot srpm, then we need to look there.

Comment 7 Frank Büttner 2009-07-05 17:14:43 UTC
[frank@homer devel]$ mock --verbose -r epel-5-i386 --rebuild qtiplot-0.9.7.4-8.fc11.src.rpm
[frank@homer devel]$
this is all output.
Yes it will happend with all srpm's.
an simple rpmbuild --rebuild will do it's job. But not mock without any error.
I have tested it with other targets all the same.

Comment 8 Clark Williams 2009-07-09 01:43:38 UTC
The fact that you're not getting *any* output means something fundamental is going wrong. What do you see when you strace the mock command?

$ strace mock --verbose -r epel-5-i386 --rebuild <some srpm>

Comment 9 Frank Büttner 2009-07-09 13:12:48 UTC
Created attachment 351069 [details]
The stacktrace output.

Comment 10 Frank Büttner 2009-07-09 13:13:13 UTC
I hope this will help.

Comment 11 Clark Williams 2009-07-09 14:34:48 UTC
well, it's certainly interesting. It's definitely something about the way your system is set up. 

The last part of the strace is where things go wrong. When mock runs, it really runs the 'consolehelper' application to verify that you have permissions to run mock (i.e. you're either root or in the mock group). The program opens a TCP socket through localhost to port 6010, which is involved with SSH.  It writes some magic stuff to the socket, sets the socket to non-blocking and tries to read a response, gets an error on the read and bails out. The reason you're not getting any output is that the process hasn't gotten to the part of starting up python.

You may want to look at how you're doing authentication.

Comment 12 Frank Büttner 2009-07-09 14:51:15 UTC
Hm, I use only a simple SSH session to the build Server.
Other python programs will run without any problems.
And I am an member of the mock group.

Comment 13 Alexander Kahl 2010-01-30 12:46:09 UTC
Hi Frank,

have you tried to:
- temporarily set SELinux to permissive mode, somethings file contexts are 
  fscked up; `tail -f /var/log/audit/audit.log` during mock runs?
- use a different (dedicated) user for mock builds?
- purge /var/{cache,lib}/mock/* and use a vanilla (unmodified) epel-5-i386 mock config file?

Are you
- using an NFS or Fuse (sshfs etc.) mounted /home (or /var)? Missing flock'ing capabilities can become a serious problem
- pre-occupying port 6010 with anything else?

Comment 14 Frank Büttner 2010-01-31 11:31:52 UTC
For testing I have complete disable selinux. -> same result.
No NFS,fuse,cifs etc. home share.
The only change at the config file is, that it use an local repo for the RPM files. But use the original will not work.
Using the another user for mock:
useradd -g users -G mock testmock
passwd testmock
add user testmock to AllowUser at ssh config.
reload sshd demon.
log in via ssh as testmock:
[testmock@homer ~]$ mock --help
[testmock@homer ~]$
same result.

Comment 15 Alexander Kahl 2010-01-31 14:05:49 UTC
Hey Frank,

some more ideas:
Try enabling/disabling (-X/-x) SSH X11 forwarding. To me the strace output looks like the MIT-MAGIC-COOKIE-1 contents are written to 127.0.0.1:6010 on fd 4, for whatever reasons - almost right after that, when trying to read back from fd 4, mock exits.

Do you have direct access to the box running mock, i.e. can you try running mock without any SSH?

Comment 16 Till Maas 2010-01-31 17:02:33 UTC
Here are some commands I would test, whether they work:

As User:
mock  clean -r fedora-12-i386

If it does not work, then as root:
/usr/sbin/mock  clean -r fedora-12-i386

Can you maybe give a developer shell access to the system to debug this easier? Or can you reproduce the problem using a CentOS Live medium?

Comment 17 Frank Büttner 2010-01-31 17:27:20 UTC
- Setting "X11Forwarding no" will not change anything.
- No, for security reasons you can't get access to the machine.
local login will work, but is not workaround because the machine has normality no keyboard+ display.

But what is interesting is that(running via ssh):

[testmock@homer ~]$ /usr/sbin/mock --help

ERROR: [Errno 1] Operation not permitted

ERROR: The most common cause for this error is trying to run /usr/sbin/mock as an unprivileged user.
ERROR: Check your path to make sure that /usr/bin/ is listed before /usr/sbin, or manually run /usr/bin/mock to see if that fixes this problem.

[testmock@homer ~]$ /usr/bin/mock --help
[testmock@homer ~]$

Comment 18 Alexander Kahl 2010-01-31 17:37:21 UTC
Well mock ought to be run by a user with group membership mock and through consolehelper (symlink /usr/bin/mock -> consolehelper) so directly running /usr/sbin/mock is not what you want anyway (the error message is correct here).
/etc/security/console.apps/mock defines the rules for running the actual mock binary through consolehelper.

Can you please try to comment out
>session         optional        pam_xauth.so<
in /etc/pam.d/mock? The X11 part of your strace log still nags me..

Comment 19 Till Maas 2010-01-31 17:43:47 UTC
(In reply to comment #17)

> But what is interesting is that(running via ssh):
> 
> [testmock@homer ~]$ /usr/sbin/mock --help

Can you please try to run it as root? It will help to distinguish, whether the problem is in mock or in the consolehelper setup that gives root privs to mock.

Comment 20 Till Maas 2010-01-31 17:51:08 UTC
(In reply to comment #19)
> (In reply to comment #17)
> 
> > But what is interesting is that(running via ssh):
> > 
> > [testmock@homer ~]$ /usr/sbin/mock --help
> 
> Can you please try to run it as root? It will help to distinguish, whether the
> problem is in mock or in the consolehelper setup that gives root privs to mock.    

I just thought about it, given that local login works, this will certainly work, so the workaroud is to use sudo instead of consolehelper to run mock.

Comment 21 Frank Büttner 2010-02-01 11:21:23 UTC
comment out "session                optional        pam_xauth.so"
don't change something "/usr/sbin/mock --help" will fail with the same error "ERROR: [Errno 1] Operation not permitted"  

run  /usr/sbin/mock --help as root will work.

Comment 22 Till Maas 2010-02-01 11:46:25 UTC
(In reply to comment #21)
> comment out "session                optional        pam_xauth.so"
> don't change something "/usr/sbin/mock --help" will fail with the same error
> "ERROR: [Errno 1] Operation not permitted"  

As non root user, you need to run /usr/bin/mock

> run  /usr/sbin/mock --help as root will work.    

So you can probably just use "sudo /usr/sbin/mock" to perform mock builds until the userhelper issue is resolved. Afaics, it is not more or less insecure than using userhelper. (It's actually userhelper not consolehelper).

I am not an sudoers/userhelper expert, but using this sudoers config:

%mock ALL= NOPASSWD: /usr/sbin/mock *

and alias mock="sudo /usr/sbin/mock" should emulate the userhelper setup.

Btw: I just stumbled upon this in man userhelper:

SESSION
  Specifies whether or not userhelper should perform PAM session management
  when running the program.  Typically this  is  needed if the PAM
  configuration uses a module such as pam_xauth.so to forward X11
  authentication tokens for use by the program.  Valid values are yes and no,
  with the default being no.

And on F12:
$ grep SESSION /etc/security/console.apps/mock 
SESSION=false

So probably just using mock already works with the updated pam config.

Comment 23 Frank Büttner 2010-02-03 08:36:05 UTC
Hello again,
I have test the follow:
add line "%mock ALL= NOPASSWD: /usr/sbin/mock *" via visudo
than log in as testmock via ssh and run:
[testmock@homer ~]$ mock="sudo /usr/sbin/mock"
[testmock@homer ~]$ mock --help
[testmock@homer ~]$

So far I can see, nothing will has changed.:(
Or have I misunderstood some think?

Comment 24 Till Maas 2010-02-03 08:44:55 UTC
(In reply to comment #23)

> [testmock@homer ~]$ mock="sudo /usr/sbin/mock"

This needs to be:
alias mock="sudo /usr/sbin/mock"

Comment 25 Frank Büttner 2010-02-05 13:14:57 UTC
Hello,
I have try it.
As an workaround it will work.
But I think we shut see, what the original problem is.
So I don't close the Bug.

Comment 26 Till Maas 2010-02-05 13:33:19 UTC
You can try to set "SESSION=true" or maybe "FALLBACK=true" in /etc/security/console.apps/mock

Comment 27 Frank Büttner 2010-02-06 08:51:52 UTC
Hello,
/etc/security/console.apps/mock contains at me:
USER=root
PROGRAM=/usr/sbin/mock
SESSION=false
FALLBACK=false

I have revert the visudo change and set
SESSION=true
FALLBACK=true

The result is the same, when call mock via ssh:
[testmock@homer ~]$ mock --help
[testmock@homer ~]$

Comment 28 Mark Chappell 2010-09-22 08:33:52 UTC
Frank, I don't know if this one is still a problem for you, but I saw something very similar last year when setting up a koji-builder instance.

What happens if you try "unset DISPLAY" before running mock.

Comment 29 Mark Chappell 2010-10-04 18:54:27 UTC
Frank, we're now up to mock version 1.0.7 are you able to confirm that this bug is still occurring for you?

Additionally if you are could you try unsetting DISPLAY prior to running mock.

Comment 30 Clark Williams 2010-12-17 18:31:24 UTC
well, if no one objects, I say we close this one.


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