Bug 510183

Since there is only a single system-wide set of options for the devpts filesystem this breaks /dev/pts also in the host system.

Patch applied, will go out in next release (0.9.17)

For systems with kernels 2.6.29 and later you should also probably use the newinstance devpts mount option to avoid any tampering with the host system.

Created attachment 350989 [details]
reworked pts mount patch

I reworked Jakub's original patch to not hardcode the 'tty' group and to add the 'newinstance' mount options if uname()[2] >= '2.6.29'. Think this will do it?

Well, it would probably do it except for the typo I introduced (+==). Fixed now.

Hmmm, looking in my 2.6.30 tree, devpts doesn't seem to have a newinstance option. Yanko, are you sure about that option and kernel version?

well, it would help if:

1. I were in the right branch of my git tree (I was in a 2.6.24 branch)

and 

2. I had my kernel compiled wiht the newinstance config option

never mind...

Ok then :) (clearing that needinfo flag) . I just tried it with rawhide userspace and f11 kernel and it works.
Speaking of rawhide , it would be nice to get a fixed mock sooner, because this issue has some unpleasant consequences -> bug 509632

Yeah, I'm working through our testing now. Figure to get a brew build out tonight and then see if we can get Jesse to up date the build boxes tomorrow.

The newinstance option has caused me a problem with mock on F-11 when trying to build perl-Expect (mock-0.9.17-3.fc11, kernel-2.6.29.6-217.2.16.fc11.x86_64). The test suite fails like this:

Executing(%check): /bin/sh -e /var/tmp/rpm-tmp.XfvLUP
+ umask 022
+ cd /builddir/build/BUILD
+ cd Expect-1.21
+ unset DISPLAY
+ /usr/bin/make test
PERL_DL_NONLAZY=1 /usr/bin/perl "-Iblib/lib" "-Iblib/arch" test.pl
IO::Tty::pty_allocate(nonfatal): grantpt(): No such file or directory at /usr/lib64/perl5/vendor_perl/5.10.0/x86_64-linux-thread-multi/IO/Pty.pm line 24.
IO::Tty::open_slave(nonfatal): ptsname_r(): No such file or directory at /usr/lib64/perl5/vendor_perl/5.10.0/x86_64-linux-thread-multi/IO/Pty.pm line 24.
IO::Tty::open_slave(nonfatal): open(/dev/pts/8): No such file or directory at /usr/lib64/perl5/vendor_perl/5.10.0/x86_64-linux-thread-multi/IO/Pty.pm line 24.
pty_allocate(nonfatal): posix_openpt(): No such file or directory at /usr/lib64/perl5/vendor_perl/5.10.0/x86_64-linux-thread-multi/IO/Pty.pm line 24.
IO::Tty::pty_allocate(nonfatal): grantpt(): No such file or directory at /usr/lib64/perl5/vendor_perl/5.10.0/x86_64-linux-thread-multi/IO/Pty.pm line 24.
IO::Tty::open_slave(nonfatal): open(/dev/pts/8): No such file or directory at /usr/lib64/perl5/vendor_perl/5.10.0/x86_64-linux-thread-multi/IO/Pty.pm line 24.
pty_allocate(nonfatal): getpt(): No such file or directory at /usr/lib64/perl5/vendor_perl/5.10.0/x86_64-linux-thread-multi/IO/Pty.pm line 24.
pty_allocate(nonfatal): openpty(): No such file or directory at /usr/lib64/perl5/vendor_perl/5.10.0/x86_64-linux-thread-multi/IO/Pty.pm line 24.
IO::Tty::pty_allocate(nonfatal): grantpt(): No such file or directory at /usr/lib64/perl5/vendor_perl/5.10.0/x86_64-linux-thread-multi/IO/Pty.pm line 24.
IO::Tty::open_slave(nonfatal): open(/dev/pts/8): No such file or directory at /usr/lib64/perl5/vendor_perl/5.10.0/x86_64-linux-thread-multi/IO/Pty.pm line 24.
pty_allocate(nonfatal): open(/dev/ptmx): No such file or directory at /usr/lib64/perl5/vendor_perl/5.10.0/x86_64-linux-thread-multi/IO/Pty.pm line 24.
Cannot open a pty at test.pl line 34
1..42
Basic tests...
make: *** [test_dynamic] Error 2
error: Bad exit status from /var/tmp/rpm-tmp.XfvLUP (%check)

This fail happens for both F-11 and devel targets.

If I comment out the two lines:

        if os.uname()[2] >= '2.6.29':
            mountopt += ',newinstance'

in /usr/lib/python2.6/site-packages/mock/backend.py, the test suite passes as before.

Perhaps some fiddling with /dev/ptmx is also needed, as mentioned in http://www.mjmwired.net/kernel/Documentation/filesystems/devpts.txt?

Seems we missed the boat for this on F12, it's too late to change out mock right now.  Punting to after F12.

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

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

Still seeing several reports of failure even with mock-0.9.19-1.fc12.noarch which is in Fedora 12.  See all the above blocked bugs.  Failures aren't happening on the buildsystems because their glibc is older.

The builders have:
$ uname -r
2.6.18-164.2.1.el5
$ rpm -q glibc
glibc-2.5-42.x86_64
glibc-2.5-42.i686
$ rpm -q mock
mock-0.9.14-2.el5.noarch

Clark, can you investigate and push out a fix?

I pulled the perl-Expect SRPM as a test platform and tried building it on my F11 laptop with:

$ mock -r fedora-11-x86_64 perl-Expect-1.21-2.fc11.src.rpm

This failed with the errors listed in other bugs (i.e. failed to create a pty). Logging into the chroot using 'mock --shell -r fedora-11-x86_64'  I noticed that while /proc/mounts reports that we have /dev/pts mounted, it does not contain the special file ptmx (which should be created as a consequence of mounting devpts). Mounting a new instance of devpts while in the chroot to /dev/foo does in fact create the ptmx file. 

Investigating further...

mock-1.0.0-1.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/mock-1.0.0-1.fc12

mock-1.0.0-1.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/mock-1.0.0-1.fc11

mock-1.0.0-1.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/mock-1.0.0-1.fc10

mock-1.0.0-1.el5 has been submitted as an update for Fedora EPEL 5.
http://admin.fedoraproject.org/updates/mock-1.0.0-1.el5

mock-1.0.0-1.el4 has been submitted as an update for Fedora EPEL 4.
http://admin.fedoraproject.org/updates/mock-1.0.0-1.el4

 mock-1.0.0-1.fc12 fixes the /dev/pty* problems.  Closing.

(In reply to comment #14)
> I pulled the perl-Expect SRPM as a test platform and tried building it on my
> F11 laptop with:
> 
> $ mock -r fedora-11-x86_64 perl-Expect-1.21-2.fc11.src.rpm
> 
> This failed with the errors listed in other bugs (i.e. failed to create a pty).
> Logging into the chroot using 'mock --shell -r fedora-11-x86_64'  I noticed
> that while /proc/mounts reports that we have /dev/pts mounted, it does not
> contain the special file ptmx (which should be created as a consequence of
> mounting devpts). Mounting a new instance of devpts while in the chroot to
> /dev/foo does in fact create the ptmx file. 
> 
> Investigating further...    

Just spotted another curiosity, which may or may not be related to this. I tried building a perl-TermReadKey package on my F-12 (x86_64) builder (devel.x86_64 target, though the target doesn't seem to matter), and the test suite, which does a bunch of stuff with /dev/tty, appears to hang. Running locally outside mock, there's no problem. If I do a koji srpm-scratch-build of the same package, it skips the test suite because it can't open /dev/tty for reading (see http://koji.fedoraproject.org/koji/getfile?taskID=1971239&name=build.log). I guess this is due to the underlying host being different?

I wonder if this is a problem that is lying in wait for us if/when the buildsystem moves on to RHEL6?

Can anybody reproduce this issue?

https://bugzilla.redhat.com/show_bug.cgi?id=609201
seems to be another incarnation rsp. a similar incarnation of this bug.

I am trying to compile python-2.7.1 on RHEL 6 with a Fedora 15 target (just to get a baseline) and I get the below - so I guess there still is something broken there...

test_pty
test test_pty failed -- Traceback (most recent call last):
  File "/builddir/build/BUILD/Python-2.7.1/Lib/test/test_pty.py", line 114, in t
est_fork
    pid, master_fd = pty.fork()
  File "/builddir/build/BUILD/Python-2.7.1/Lib/pty.py", line 107, in fork
    master_fd, slave_fd = openpty()
  File "/builddir/build/BUILD/Python-2.7.1/Lib/pty.py", line 29, in openpty
    master_fd, slave_name = _open_terminal()
  File "/builddir/build/BUILD/Python-2.7.1/Lib/pty.py", line 70, in _open_termin
al
    raise os.error, 'out of pty devices'
OSError: out of pty devices
Re-running test 'test_pty' in verbose mode
test_basic (test.test_pty.PtyTest) ... skipped 'Pseudo-terminals (seemingly) not
 functional.'
test_fork (test.test_pty.PtyTest) ... ERROR
======================================================================
ERROR: test_fork (test.test_pty.PtyTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/builddir/build/BUILD/Python-2.7.1/Lib/test/test_pty.py", line 114, in t
est_fork
    pid, master_fd = pty.fork()
  File "/builddir/build/BUILD/Python-2.7.1/Lib/pty.py", line 107, in fork
    master_fd, slave_fd = openpty()
  File "/builddir/build/BUILD/Python-2.7.1/Lib/pty.py", line 29, in openpty
    master_fd, slave_name = _open_terminal()
  File "/builddir/build/BUILD/Python-2.7.1/Lib/pty.py", line 70, in _open_terminal
    raise os.error, 'out of pty devices'
OSError: out of pty devices
----------------------------------------------------------------------
Ran 2 tests in 0.006s
FAILED (errors=1, skipped=1)
test test_pty failed -- Traceback (most recent call last):
  File "/builddir/build/BUILD/Python-2.7.1/Lib/test/test_pty.py", line 114, in test_fork

I'm abusing mock a bit to allow me to run some scripts inside a chroot easily, and I found that if I use pexpect inside the chroot (any distro) it fails with a very similar error:


     File "/tmp/run/.tox/functional/lib/python2.7/site-packages/pexpect/__init__.py", line 511, in __init__
       self._spawn(command, args)
     File "/tmp/run/.tox/functional/lib/python2.7/site-packages/pexpect/__init__.py", line 630, in _spawn
       raise ExceptionPexpect('pty.fork() failed: ' + str(err))
   pexpect.ExceptionPexpect: pty.fork() failed: out of pty devices


Is there a workaround to this?

It actually seems to happen only if I specifically mount the /dev on the mock options, if letting mock populate it it works well... but I need some of the devices there...