Bug 613392

I can easily rebuild bash with rpmbuild (not in mock). Assigning to mock.

i can also easily rebuild with rpmbuild, but imho it's still not a mock issue. the bug is in the check part of the spec file while waiting for something which is not available during background/non interactive/chroot shell. so it'd have to fix in bash spec or bash's Makefile's check target.

In RHEL the official way to (re)build packages is with direct rpmbuild.
I will look deeper what's going on and possibly fix it in Fedora.
The build gangs in the test when executing execscript.

Bash hangs when run in mock chroot trying to run interactively - opening /dev/tty.

does it normal to do it during the build?

Depends on what is "normal". This occurs only in the check routine.

This bug appears to have been reported against 'rawhide' during the Fedora 14 development cycle.
Changing version to '14'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Changing component to mock itself. Maybe there can be something changed in mock, so the bash can borrow /dev/tty for a while. If not, there will needed some dirty hack...

This looks similar to Bug #609201.

Yep. Similar or same.

is there any progress with it?
it seems rhel-6's bash still has the same problems...

is there any list for mock or where is the mock development happened? mailing list or something like that? or should i ask here?
it seems most of the mock problem in the current release comes from the %check section of the rpmbuild. there are 4,5 different bz about it.
is there any mock option to switch off the rpmbuild check part from the build? it can solve a lots of issue until someone can fix mock and different packages.
thanks.

Development discussion usually takes place on the fedora-buildsys-list (but it's been pretty quiet lately. I apologize for the lack of movement on this bug, but I'm coming out of a release cycle so I'll be able to do mock things now. 

I suspect that this and https://bugzilla.redhat.com/show_bug.cgi?id=609201 are both symptoms of tty issues (ugh).

it's not just tty, the same happened with guile, bash, zsh, jna and many others.
they all build with rpmbuild but not in mock because of different reason, but all failed in %check section so it'd be useful feature for mock.

I think you misunderstand what is being said. tty is not a package but the current terminal device. There seems to be in issue where this device is not properly passed to the mock root.

At least the failing of the build of bash is an issue that has to do with this. The execscript test starts an interactive shell (bash -i ./exec8.sub) which is where the build stalls.

By the way, if you chroot to the mock root and su - mockbuild you can complete the build by just starting a
$ rpmbuild -ba bash.spec

no i understand it. i just said that there are many other packages which fail in the %check section with mock-1.1.5 (not just tty related bug) while it was build with mock-0.6.3. so it'd be a useful feature for mock to disable the %check part during build.

half of the rhel-6's perl packages also fail in the %check section (i don't they are tty related or not).

I finally got a RHEL6 box setup and duplicated your hang. 

in a separate window I did:

$ ps -Ao state,tty,wchan:20,cmd

and found this group of threads:

T pts/0    signal_stop          /bin/sh -e /var/tmp/rpm-tmp.zAHwbl
T pts/0    signal_stop          make check
T pts/0    signal_stop          /bin/sh -c ( cd ./tests && \??PATH=/builddir/build/BUILD/bash-4.1/tests:$PATH THIS_SH=/builddir/bui
T pts/0    signal_stop          /bin/sh -c ( cd ./tests && \??PATH=/builddir/build/BUILD/bash-4.1/tests:$PATH THIS_SH=/builddir/bui
T pts/0    signal_stop          /bin/sh run-all
T pts/0    signal_stop          sh run-execscript
T pts/0    signal_stop          /builddir/build/BUILD/bash-4.1/bash ./execscript
T pts/0    signal_stop          /builddir/build/BUILD/bash-4.1/bash -i ./exec8.sub


So everything looks like it's stuck in the T state, meaning:

 T    Stopped, either by a job control signal or because it is being traced.

Since the wchan is signal_stop, I'd guess that we somehow got a job control signal and things went bad from there. Not sure why this is hanging, since the same rpm gets built on both f13 and f14, which are relatively new kernels and should have the same pseudo-terminal behavior as the RHEL6 kernel. 

Continuing to debug...

After trying to build bash for x86_64 on a RHEL6 system, I did this:

$ sudo ./py/mock.py -r epel-6-x86_64 --shell
mock-chroot> cd /builddir/build/BUILD/bash-4.1
mock-chroot> make check

<lots of output about testing>

run-execscript
warning: the text of a system error message may vary between systems and
warning: produce diff output.
warning: if the text of the error messages concerning `notthere' or
warning: `/tmp/bash-notthere' not being found or `/' being a directory
warning: produce diff output, please do not consider this a test failure
warning: if diff output differing only in the location of the bash
warning: binary appears, please do not consider this a test failure

[1]+  Stopped(SIGTTIN)        make check
mock-chroot> 

So, something in bash's run-execscript is trying to do an interactive read from the terminal. Or at least that's what the system *thinks* is happening. 

Any thoughts?

as i wrote to the epel list 
mock --shell
rpmbuild ...
will work in both zsh and bash case. so it should have to be something with interactive/none interactice shell/terminal settings durng build.

I'm not familiar with python, but I guess the python is blocking /dev/tty. Maybe it is possible to unlock it or share... don't know, just shooting

> So, something in bash's run-execscript is trying to do an interactive read from
> the terminal. Or at least that's what the system *thinks* is happening. 

The trace at the top says it:
tests/execscript calls
bash -i ./exec8.sub

I.e. it uses an interactive bash shell for that last test. Even that symlink from /dev/tty to /dev/ptmx I proposed in bug 609201 doesn't fix this issue. Ripping out /dev/tty from the buildroot altogether does, which is why koji does not fail to build this package.

so what about if we remove /dev/tty in the build case and symlink it for the --shell case?

Hmmm, now I'm wondering if we just need to nuke /dev/tty from inside the chroot?

Would it make sense to have a config variable 'setup_dev_tty' that's normally False, but can be set to True and would cause mock to setup /dev/tty inside the chroot (in case there's a package out there that desperately needs /dev/tty or checks it for existance, etc.)?

why not always? does it expensive?

Clark, I suggest you ask one of the kernel guys at Red Hat to look into this. Linking /dev/ptmx to /dev/tty as I proposed for bug 609201 seemed a good idea but I can't vouch for the correctness of the approach. Perhaps it is indeed correct and the fact that this bash build fails is a problem with python as Roman suggests but I don't claim to be an authority on these matters so I can't tell you for sure. I just tried something that seemed logical, or at least a path worth exploring. That approach fixed the other issue but not this one, so you should put it to someone with more knowledge of these matters.

heh, fact is that I'm a kernel guy at Red Hat :). What I'm *not* is familiar with the tty subsystem.

We need to find someone that knows how the tty system has changed from 2.6.9 to the present. I'll see if I can dig someone up.

another (may be) useful tip, is this working with mock-0.6.x...

Me having the same problem trying to rebuild bash with mock
-) fedora 14 (plus all updates until today)
-) x86_64
-) processes hanging in T state
-) does rebuild with rpmbuild

@ Roman Comment 4

After the discussion on this bug
https://bugzilla.redhat.com/show_bug.cgi?id=432194
I was thinking "mock" is the preferred build environment.

What is the current preferred way to rebuild for Fedora?

(In reply to comment #31)
> @ Roman Comment 4
> 
> After the discussion on this bug
> https://bugzilla.redhat.com/show_bug.cgi?id=432194
> I was thinking "mock" is the preferred build environment.
> 
> What is the current preferred way to rebuild for Fedora?

I don't know. Maybe not any one :)
Koji is using mock for building and most likely it is using some older version. How much builds are failing with newer mock? It make sense to not run tests requiring access to controlling terminals in non-interactive builds. But how to determinate it?

1.1.19 solve it:-)

"mock-1.1.9-1.fc14.noarch.rpm" works for me also.