[Python-Dev] Python 2.0 beta 2 pre-release

[Thomas Wouters]

On Tue, Sep 26, 2000 at 03:43:42PM -0400, Fred L. Drake, Jr. wrote:

>   The failing tests are for fcntl, openpty, and pty.  Here's the
> output of regrtest -v for those tests:

> bash$ ./python -tt ../Lib/test/regrtest.py -v test_{fcntl,openpty,pty}
> test_fcntl
> test_fcntl
> Status from fnctl with O_NONBLOCK:  0
> struct.pack:  '\001\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000'test test_fcntl crashed -- exceptions.IOError: [Errno 37] No locks available
> Traceback (most recent call last):
>   File "../Lib/test/regrtest.py", line 235, in runtest
>     __import__(test, globals(), locals(), [])
>   File "../Lib/test/test_fcntl.py", line 31, in ?
>     rv = fcntl.fcntl(f.fileno(), FCNTL.F_SETLKW, lockdata)
> IOError: [Errno 37] No locks available

Looks like your /tmp directory doesn't support locks. Perhaps it's some kind
of RAMdisk ? See if you can find a 'normal' filesystem (preferably not NFS)
where you have write-permission, and change the /tmp/delete-me path in
test_fcntl to that.

> test_openpty
> test_openpty
> Calling os.openpty()
> test test_openpty crashed -- exceptions.OSError: [Errno 2] No such file or directory
> Traceback (most recent call last):
>   File "../Lib/test/regrtest.py", line 235, in runtest
>     __import__(test, globals(), locals(), [])
>   File "../Lib/test/test_openpty.py", line 9, in ?
>     master, slave = os.openpty()
> OSError: [Errno 2] No such file or directory

If you're running glibc (which is pretty likely, because IIRC libc5 didn't
have an openpty() call, so test_openpty should be skipped) openpty() is
defined as a library routine that tries to open /dev/ptmx. That's the kernel
support for Unix98 pty's. However, it's possible that support is turned off
in the default Caldera kernel, or perhaps /dev/ptmx does not exist (what
kernel are you running, btw ?) /dev/ptmx was new in 2.1.x, so if you're
running 2.0 kernels, that might be the problem.

I'm not sure if you're supposed to get that error, though. I've never tested
glibc's openpty() support on a system that had it turned off, though I have
seen *almost* exactly the same error message from BSDI's openpty() call,
which works by sequentially trying to open each pty, until it finds one that
works. 

> test_pty
> test_pty
> Calling master_open()
> Got master_fd '5', slave_name '/dev/ttyp0'
> Calling slave_open('/dev/ttyp0')
> test test_pty skipped --  Pseudo-terminals (seemingly) not functional.
> 2 tests failed: test_fcntl test_openpty
> 1 test skipped: test_pty

The 'normal' procedure for opening pty's is to open the master, and if that
works, the pty is functional... But it looks like you could open the master,
but not the slave. Possibly permission problems, or a messed up /dev
directory. Do you know if /dev/ttyp0 was in use while you were running the
test ? (it's pretty likely it was, since it's usually the first pty on the
search list.) What might be happening here is that the master is openable,
for some reason, even if the pty/tty pair is already in use, but the slave
isn't openable. That would mean that the pty library is basically
nonfunctional, on those platforms, and it's definately not the behaviour
I've seen on other platforms :P And this wouldn't be a new thing, because
the pty module has always worked this way.

-- 
Thomas Wouters <thomas@xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!